On Sat, Dec 27, 2014 at 9:30 PM, Alejandro Dubrovsky <[email protected]> wrote: > > Hi all, > > When running a small, low traffic site on slow cloud servers (eg > DigitalOcean), it'd be useful to be able to cache pages, not because the > site might be taken down from too many request, but to improve > responsiveness. A non-trivial page that might take a few hundredth of a > second to server on a local desktop might take over a second on a slow > server, but that times goes back down to less than a hundredth of a second > when cached. Ideally, I'd want to pre-generate most of the popular pages on > a site but not send a large max-age, so that if the content does change, > the new pages can be regenerated and stale content would not be served. > > At the moment, the Django cache framework ties up how long it thinks the > cached values are valid with what it sends the client with max-age (eg if > you set CACHE_MIDDLEWARE_SECONDS to 600, it'll send a max-age of 600, and > set the validity of the server-side content valid for 600 seconds). It > ignores the CACHES[cache]['TIMEOUT'] and goes by CACHE_MIDDLEWARE_SECONDS, > or its per-view parameter equivalent. I think it would be useful to be able > to separate the two, keeping server-stored caches valid for a long time (or > indefinitely until they are forcefully invalidated), while sending a small > max-age (or none at all). A CACHE_MIDDLEWARE_CLIENT_SECONDS setting would > seem appropriate, or maybe a setting to tell it to respect > CACHES[name]['TIMEOUT'] for server-side validity checking. > > I can prepare a patch if the idea seems worthwhile to others. >
Hi Alejandro, I can see how the case you describe would lead to computed cache content having long validity, but that validity not necessarily being the same as the appropriate max-age for the client. There are some related cases that would be good to control - for example, if you receive a request near the end of the lifespan of a cached value, you'll effectively double the lifespan of the cached value in the wild, because you'll return a long max-age to the client just before the value actually expires. So: yes, I think a patch for this feature would be worthwhile. >From an implementation point of view, the addition of a new setting is the only point of concern - we generally try to avoid adding a new setting unless we have to. However, in this case, there really is a new thing being configured here, so a new setting makes sense to me. The only caveat I would flag is the backwards compatibility path; existing users won't have CACHE_MIDDLEWARE_CLIENT_SECONDS defined, so the implementation will need to fall back to CACHE_MIDDLEWARE_CLIENT_SECONDS = CACHE_MIDDLEWARE_SECONDS if it the new setting isn't provided. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84_dJEG%3DDuX_BEm714wbwQqgg%2BdUmsvOhxb9gNo6ggNZ%3Dw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
