Huge Unexplained Drop-off in Cached Requests!

#1

Evening All,

I configured CloudFlare for my Wordpress blog about a week ago, and absolutely love it. The analytics blew my mind – approximately 80% of my bandwidth and requests were being served from the blazing fast CloudFlare cache.

However, I looked in upon my analytics a few hours ago and was shocked to see that over the last couple of days the graph has completely inverted, such that now only a tiny fraction of requests are hitting the cache, and almost all requests are uncached (see attached screenshot).

I have no idea what I might have changed that could have caused this. I did setup 3 Page Rules at the weekend (see attached), but I can’t see how any of them are relevant. The first rule just redirects from my landing page to another page, the second rule excludes the WordPress admin section from SSL, and the third rule enforces SSL for the rest.

Please help, CloudFlare Community! Any and all advice/wisdom, much appreciated,

All the Best,
Al

Cached Request Drop Off.png1462×721 64.2 KB

Page Rules.png1436×393 46.1 KB

#2

From my side everything on site (statics) is cached (at least on front page).

PS. You don’t have to waste Page Rule on “Always Use HTTPS”. For couple of days it can be done from panel (I believe crypto tab).

#3

Thanks for the reply KomarEX. It’s strange, the analytics definitely state that most requests aren’t being cached, for whatever reason.

I’ll probably remove the page rules to see if that makes a difference. I did originally have ‘Always Use HTTPS’ enabled from the Crypto tab, but adding it as a page rule instead, preceded by a higher priority page rule NOT configuring HTTPS for the WordPress admin sub-domain, was the only way I could get the WordPress admin to work correctly.

Otherwise, I was having to turn on and off HTTPS on the Crypto tab every time I needed to login to the WordPress admin…which I will return to doing if it means my caching works correctly again, but is a pain!

#4

Doh! I made a stupid and obvious error. The second page rule above bypasses the cache for wp-*. But that pattern doesn’t just match the WordPress admin and login page – it also matches a folder were images and other assets are stored.

It’ll take a while for the analytics graph to prove it, but I believe I’ve found the problem (thank God!).