0

I use google CDN with google load balancer, which has a few backend services and each has different setting for google CDN, like following. 

service A: google CDN disabled (API server)
service B: google CDN enabled, 1day (Cache-Control: public, max-age=86400), cache-key: full URL
service C: google CDN enabled, 1year (Cache-Control: public, max-age=31536000), cache-key: full URL

problem is, service C got request from google load balancer, which URL is already requested yesterday and processed correctly. (status 200, with Cache-Control header and Content-Length)

it does not happen always, for example, just after returns response from our server, google load balancer returns response without querying. but about a day passed, they start to ask again. note that I made request almost same geographic location.

after some googlng, I already found following link on SO, which says google CDN evict its contents aggressively (says only 10MB cache size in total), https://stackoverflow.com/a/54031267/1982282

and google CDN does not assure to respect max-age. Google Cloud CDN ignores max-age over 3600

but the reason of above issues are, really this aggressive eviction?

actually, our server still in development phase so does not have large amount of traffic, also total cache sizes are only ~ 10MB or some. but in my personal feeling, I cannot believe google CDN evicts contents that hard (within 1day, 10MB+ in size).

could anyone share your experience about google CDN eviction rate?

regards,

takehiro iyatomi
  • 753
  • 1
  • 7
  • 20
  • 2
    Most CDNs will evict content accessed only a handful of times within a day, if not sooner, since CDN caches are designed to run at close to capacity. If your content isn't public / others aren't accessing it, you'll find it's evicted fairly quickly. This often applies when you're just testing things out and only you are accessing it. Note that total cache sizes are _not_ 10MB - the linked answer may have interpreted the maximum size of objects (10MB for legacy web-servers, which is rare!). Nearly all modern webservers support Range requests, which means the max per-object size is 5TB. – elithrar Dec 16 '19 at 22:20

1 Answers1

1

In brief, the CDN cache contents and consequently the cache hits are affected by several independent factors, in particular by the cache content eviction, content expiration, user request intensity and size. Apart from that, Cloud CDN can initiate other requests as part of caching algorithm: i.e. validation requests and byte range requests.

Hence you shouldn't expect the requests to the origin servers to stop by tuning a single parameter, such as max-age.

As the Google Cloud CDN documentation mentions,

For content to be served from a cache, it must have been inserted into the cache, it must not be evicted, and it must not be expired.

The evicted content might be expired, and it might not be. Setting an expiration time doesn't affect eviction.

As caches receive more traffic, they also evict more cached content.

Because of the nature of caches, it is impossible to predict whether a particular request will be served out of cache.

It would be rather incorrect speaking about any kind of "aggressive eviction" of the cache content. The Cloud CDN cache just behaves exactly as it should. This behavior is clearly described here:

Google Cloud CDN: Overview

Google Cloud CDN: Caching Details

This documentation also explains the two other "issues" mentioned here in regards the question.

Community
  • 1
  • 1
mebius99
  • 2,495
  • 1
  • 5
  • 9
  • thanks for advice. but as I wrote in question, I understand its impossible to control cache expiration perfectly by max-age or something (also I've already read suggested link), but compared with other CDN like cloudfront, google CDN seems to make cache expire too early, so I want to know other peoples experience, especially whether behaviour is same for production environment or not, which has much access than develop one. if other people also has same duration for 1yr-max-age cache in prod, that means we just have to try to use other one, which is "less aggressive". – takehiro iyatomi Dec 16 '19 at 05:18