On Sun, Jan 17, 2010 at 11:35 PM, Dami Laurent (PJ) < laurent.d...@justice.ge.ch> wrote:
> > > > Indeed, this is exactly what I want to do. The app has a config file (not a > Catalyst > config file, but another file having to do with business logic), and some > super-users > have a mechanism for hot uploading of a new config to the server, at any > time. > 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 uploaded. 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. -- Bill Moseley mose...@hank.org
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
