On Sun, Jan 17, 2010 at 11:35 PM, Dami Laurent (PJ) wrote:
Indeed, this is exactly what I want to do. The app has a config file (not a
config file, but another file having to do with business logic), and some
have a mechanism for hot uploading of a new config to the server, at any
A few app pages are expensive to compute, and they depend on the client and
on that config file. So clients should keep asking for those pages at each
request, and depending on the If-Modified-Since header and on the timestamp
for the config file, the server can decide if it's worth recomputing the
page for that client, or rather send a cheap 304 Not Modified.
Be careful about using timestamps if you are running multiple web servers
behind a load balancer (or may expand to where you will be behind a
balancer). Here's a read on Etags:http://developer.yahoo.net/blog/archives/2007/07/high_performanc_11.html
For resources such as css, js, images I tend to create URLs that include an
md5. Those include cache headers that don't expire and thus when the
content changes the URL changes.
I have also done that with text/html pages, but it's less common. For a
config file you can send the config through Object::Signature to get an
md5. You could recalculate and cache that whenever a new config is
For "static" pages (for non-logged in users) the pages tend to get cached
for some number of minutes as it's not critical that a change is seen
exactly the same time by all users. Dynamic content is not cached, of
course, but elements of the page may be cached in memcached.