APO – Requests hitting cache also hitting origin server

Performance
#1

Hi,

I noticed today that all requests hitting the APO cache and returning cf-cache-status: HIT are also hitting my origin server.

Fortunately, I have a page cache system in place on my server, so those requests are all returning cached pages that don’t take up much resources. But if a server doesn’t use a page cache system, it means all requests could eventually overload the server if they’re all hitting PHP instead of a cache.

The issue seems to only occur with cached HTML and NOT images or other static resources.

I was able to duplicate the issue on different browsers and platforms. To test, I simply refreshed different pages many times and noticed all requests created as many entries in my server’s access log. I believe requests filled by APO that return cf-cache-status: HIT should never hit the origin server, unless I’m misunderstanding something (maybe @yevgen can enlighten me on the matter).

I would be curious to know if anyone else can reproduce this APO behaviour.

Edit: I did a simple test and found something rather interesting. I disabled APO and made sure it was completely deactivated by checking that the cf-cache-status header returned DYNAMIC. Then, I activated a Cache Everything Page Rule for www.website.com/*. After refreshing a page a few times and getting cf-cache-status: HIT, I noticed the requests did NOT hit my origin server as there were no entries in the access log.

Edit: Interestingly enough, I disabled my local Page Cache and requests were not being logged in the origin server’s access log file anymore. So I guess this behaviour has to do with having APO on top of a server cache. I will close this ticket as it is probably not a real world issue.

#2

Is this a live website with real traffic or a closed test environment?

Were you refreshing with ctrl+F5? Or you have disabled cache via dev tools? If you’re using Chrome / Brave, or probably any modern browser, force refresh is actually modifying the HTTP request sent from your browser which instructs (Cloudflare / your origin) to revalidate the content. So, it was a clean hit at first, but you asked for the machine to go back and check to make sure, so off it went to investigate your origin server. That’s my understanding of it, anyway.

If it’s a live website with other real traffic, then it’s probably not any of the above. Check some of the other CF cache responses (cf-edge-cache, etc.) and post them here. Maybe that’ll help.

#3

Hi,

Thanks for your tips. It is indeed a live website. I am refreshing using F5 and NOT disabling the browser’s cache. I believe there might be a flaw in the way APO manages cached responses, where it reaches out to the origin server when it shouldn’t.

We’ll see what the APO developers have to say about this.

#4

Might be related APO caching dropped significantly

#5

Thanks for linking to that post @eva2000.

It seems like my caching percentage has also dropped from 99% to 85% on October 22. Not sure if it’s related, but it is interesting nevertheless.

If you have some spare time, I would be curious to know if you are seeing the same thing with your server’s log file when refreshing a web page that is cached by APO. That is, if each page refresh creates a log entry in your server’s access log.

#6

Currently not using APO cache but my own CF worker based caching and pretty much stays between 96-98% cache hit rates

1 Like
#7

I was doing the same until APO came out. Then I thought APO could replace my own solution since it seemed very promising and had all the features of my custom Worker. So I’ve been running and testing my website on APO for the past week or so, but it seems like there are still some fundamental flaws that might see me going back to my own Worker until they are sorted out.

#8

Yes, I am keeping a close eye on APO and looking for when it matures to retest it. Like API tokens don’t always work as there’s a bug in regex evaluating them right now so some API tokens don’t work while some do. So I can only use Global API keys. Next release should have API token bug fixed.

#9

Interestingly enough, I disabled my local Page Cache and requests were not being logged in the origin server’s access log file anymore. So I guess this behaviour has to do with having APO on top of a server cache. I will close this ticket as it is probably not a real world issue.

#10

After doing more tests over the last couple of days and looking at my server’s access log and analytics, I realized that this is still an issue and many requests are still hitting my origin server even after disabling my local Page Cache.

When I disable the Page Cache, my server’s CPU usage jumps from 0.30% to 4% and data transfer jumps from 100 Kbps to 2 Mbps.

I am having a hard time reproducing the issue and I can’t figure out why so many requests are hitting my server. When I test different URLs in different browsers, I always get cf-cache-status: HIT.

When I look in the Cloudflare Dashboard at the Cache Performance Analytics, I can see there are hundreds of DYNAMIC requests per hour, mostly for regular posts.

And just so you know, when I use a custom Worker to Cache Everything instead of APO, the issue completely disappears.

I’m thinking it could be related to the HTTP/1.1 version bug that @yevgen mentioned in another thread since around 10% of all requests to my website are made via HTTP/1.1.

#11

Do you use Cloudflare for WordPress plugin integration with APO?

#12

I have version 3.8.5 in use.

#13

Yes I do, version 3.8.5.

#14

For a few weeks after activating APO my Cache Percentage went up to 98-99% from an average of around 50-60%.

However around middle of October it started dropping at around 8% a day until it got back to pre APO Figures.

I do have a Support Request but they are unable to answer why there was a dramatic increase after activating APO, then a steady drop.

#15

This was apparently a analytics error that was corrected after 22nd Oct.
There was a dedicated post about this here APO caching dropped significantly

1 Like