Feature Request P2
Status Update
No update yet.
Comments
f....@gmail.com
Doesn't seem to be implemented on GAE/Java.
sd...@gmail.com
Although I said this doesn't need to be documented -- the idea being that because of the nature of the caching, your app needs to work whether it is present or not -- there are many implementation details of HTTP caching which influence how you write code for best performance. Some of these details could be determined by experiment, but they are also likely to change as Google tunes the implementation and adds features.
For this reason it would be most helpful if Google would document how the HTTP reverse caching proxy works. Here are some questions I have:
1) Is there a lower bound on entity size? Will a full size 10MB entity be cached?
2) Is there a min/max ttl? Can an entity be cached for 30 sec, 10 sec?
3) Will response codes other 200 be cached? Redirects? Errors?
4) Will a response with a X-AppEngine-BlobKey header be cached and future requests directed to the high-performance blob serving infrastructure, somewhat like get_serving_url()?
5) Is the Vary header handled, or does this disable caching? Is there a limit to how many headers may vary? May the Set-Cookie header vary?
6) Will the cache serve byte ranges?
7) Will the cache serve dynamically gzipped entities?
8) Is the s-maxage cache-control directive supported? Which other HTTP Cache-Control directives are supported?
9) Does the cache revalidate stale entities? Using which mechanisms, and under which circumstances?
10) How big is the cache?
For this reason it would be most helpful if Google would document how the HTTP reverse caching proxy works. Here are some questions I have:
1) Is there a lower bound on entity size? Will a full size 10MB entity be cached?
2) Is there a min/max ttl? Can an entity be cached for 30 sec, 10 sec?
3) Will response codes other 200 be cached? Redirects? Errors?
4) Will a response with a X-AppEngine-BlobKey header be cached and future requests directed to the high-performance blob serving infrastructure, somewhat like get_serving_url()?
5) Is the Vary header handled, or does this disable caching? Is there a limit to how many headers may vary? May the Set-Cookie header vary?
6) Will the cache serve byte ranges?
7) Will the cache serve dynamically gzipped entities?
8) Is the s-maxage cache-control directive supported? Which other HTTP Cache-Control directives are supported?
9) Does the cache revalidate stale entities? Using which mechanisms, and under which circumstances?
10) How big is the cache?
sd...@gmail.com
The Vary bug is still not fixed, so here is a new bug for it:
http://code.google.com/p/googleappengine/issues/detail?id=4277
Hopefully it will get some attention as it is reasonably serious.
Hopefully it will get some attention as it is reasonably serious.
sd...@gmail.com
- The cache will be flushed when you redeploy
- The cache is available for Google Apps domains, but
Also, it seems to work whether billing is enabled or not.
sa...@gmail.com
- The cache is available for Google Apps domains, but appspot.com domains
Is this a typo? Did you mean "but *not* forappspot.com domains"?
Is this a typo? Did you mean "but *not* for
sd...@gmail.com
Woops, yes that's a typo. The appspot.com domain is NOT supported, according to the info at the link provided. Maybe this will change in the future.
gr...@google.com
ja...@gmail.com
Just created #5576 requesting an option to disable access to an app via its appspot domain if it has a Google Apps domain. Since the edge cache is disabled for the appspot domain, this would reduce vulnerability to DoS attacks.
ja...@gmail.com
pr...@google.com
Will try to reproduce this issue, and followup there.
sd...@gmail.com
New info, via:
https://groups.google.com/d/topic/google-appengine/6xAV2Q5x8AU/discussion
"If you want edge caching to work you need to make sure you have done the following things:
1. Set Public If you don’t set public it won’t be cached ever.
2. Set a max-age . If you set public but don’t specify max-age it won’t be cached
3. Use a comma. public, max-age=300 works fine. Public; max-age=300 does not.
4. Set an age greater than 60. 61 seems to cache. 60 does not. There is probably some volume to will I cache based on expiration but 61 seconds at the volumes we run seems to cache and 60 doesn’t ever seem to.
5. Set an age less than 366 days. 364 days seems to work 365 works most the time 366 never seems to work. So those “Expire never” kinds of posts people talk about for versioned assets that never expire. Well 10 years is not the right answer.
6. Expires with a date, doesn’t seem to help, and seemingly may prevent caching in some instances. I think this may be clock drift. Or something about how picky the parser is about the format of the date. Things that work in browsers don’t always work correctly in the edgecache… (like the Semi vs the comma)
7. Set both Pragma and Cache-Control If Pragma is not set Public then Cache-Control seems to be ignored.
"If you want edge caching to work you need to make sure you have done the following things:
1. Set Public If you don’t set public it won’t be cached ever.
2. Set a max-age . If you set public but don’t specify max-age it won’t be cached
3. Use a comma. public, max-age=300 works fine. Public; max-age=300 does not.
4. Set an age greater than 60. 61 seems to cache. 60 does not. There is probably some volume to will I cache based on expiration but 61 seconds at the volumes we run seems to cache and 60 doesn’t ever seem to.
5. Set an age less than 366 days. 364 days seems to work 365 works most the time 366 never seems to work. So those “Expire never” kinds of posts people talk about for versioned assets that never expire. Well 10 years is not the right answer.
6. Expires with a date, doesn’t seem to help, and seemingly may prevent caching in some instances. I think this may be clock drift. Or something about how picky the parser is about the format of the date. Things that work in browsers don’t always work correctly in the edgecache… (like the Semi vs the comma)
7. Set both Pragma and Cache-Control If Pragma is not set Public then Cache-Control seems to be ignored.
ja...@gmail.com
Quoting Comment 6 by sdeasey, Dec 18, 2010:
>https://groups.google.com/d/msg/google-appengine/8QgEUBOiNFw/m4O5quSO8q0J
>
> - The cache will be flushed when you redeploy
Just got the edge cache to work for the first time thanks to Brandon's tips (quoted in previous comment), but in my testing I've caused a response to be cached for a whole year by setting "s-maxage". (Kicking myself for not using a smaller value; was only paying attention to max-age.) I thought the edge cache would be flushed on redeploy thanks to the above, but after redeploying, the edge cache is still serving this stale response, in production, no less, since the edge cache doesn't work on appspot domains.
So is there any way to flush the cache? The edge cache continues to serve stale responses for the cached url even after disabling the app.
>
>
> - The cache will be flushed when you redeploy
Just got the edge cache to work for the first time thanks to Brandon's tips (quoted in previous comment), but in my testing I've caused a response to be cached for a whole year by setting "s-maxage". (Kicking myself for not using a smaller value; was only paying attention to max-age.) I thought the edge cache would be flushed on redeploy thanks to the above, but after redeploying, the edge cache is still serving this stale response, in production, no less, since the edge cache doesn't work on appspot domains.
So is there any way to flush the cache? The edge cache continues to serve stale responses for the cached url even after disabling the app.
ja...@gmail.com
Between yesterday and today something caused the stale response to be flushed from the cache after all. If it was something I did, it took a while to kick in.
pr...@google.com
fr...@gmail.com
This issue has been accepted quite some time ago, but nobody has been assigned yet.
ab...@gmail.com
No word yet? I'd really like to know under what conditions edge caching won't be leveraged as my app isn't serving any cached requests right now. Query cursors?
jp...@pettitt.net
Bump. another year and still no doc ...
[Deleted User] <[Deleted User]>
I'll bump this as well. It's been far too long. Now that the Cloud CDN has been documented, it seems like the cat is out of the bag. Can someone please document how the Appengine GFEs are different than the Cloud CDN GFEs?
https://cloud.google.com/cdn/docs/caching
[Deleted User] <[Deleted User]>
Does this page help resolve this ticket? https://cloud.google.com/appengine/docs/standard/python3/how-requests-are-handled#response_caching
(That's for Python 3, standard environment; I assume the GFE works the same for other environments but I don't know if the documentation exists for others)
(That's for Python 3, standard environment; I assume the GFE works the same for other environments but I don't know if the documentation exists for others)
he...@gmail.com
^ That page helps! It's too short - ideally the questions in
Description
response, then the App Engine infrastructure should act as if there were a
caching reverse-proxy server in front of my app.
The next request for the same URL should be served directly from the cache
without an instance of my app being started.
The amount of cache space, should be determined by App Engine, as memcache
space is. Responses with cache-control headers could be sampled by App
Engine; those with the most frequent requests would stay in cache longer.
The advantages would be: 1) less cpu/memory usage by my app to serve what
are basically static resources; 2) higher requests per second without
running more instances; 3) cached content served by Google's geographically
dispersed, low-latency edge servers.
This is a model familiar to many web developers and requires no extra APIs,
or even documentation. It is good practice to cache-control headers.