[Catalyst] Re: modules for conditional GET ?

2010-01-18 Thread Aristotle Pagaltzis
* Dami Laurent (PJ) laurent.d...@justice.ge.ch [2010-01-18 08:35]:
 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.

I suggest you send an ETag and check `If-None-Match` (possibly
just a hash of the timestamp for the config file) instead of
(or if you have HTTP/1.0 clients, in addition to) relying on the
timestamp and `If-Modified-Since`.

Beyond that:

It’s easy to write a module that will conserve bandwidth using
these headers, by hashing the body after all computation is done
and checking whether to send it or just a 304.

But conserving server CPU requires intimate knowledge of both the
model and the structure of the controllers. It seems hard to find
a generically useful abstraction beyond a utility method or two
for setting the headers.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.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/


Re: [Catalyst] Re: modules for conditional GET ?

2010-01-18 Thread Bill Moseley
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/


RE: [Catalyst] Re: modules for conditional GET ?

2010-01-17 Thread Dami Laurent (PJ)
 

-Message d'origine-
De : Aristotle Pagaltzis [mailto:pagalt...@gmx.de] 
Envoyé : samedi, 16. janvier 2010 15:34
À : catalyst@lists.scsys.co.uk
Objet : [Catalyst] Re: modules for conditional GET ?

* Dami Laurent (PJ) laurent.d...@justice.ge.ch [2010-01-14 16:05]:
 For some actions of a Catalyst app, I would like to implement
 conditional GET (using If-Modified-Since HTTP header), where
 the timestamp of one config file decides whether the page
 should be refreshed or not  --- this is because that page is
 quite expensive to compute.

I agree with the others who have responded, but they didn't
explain why theirs was the right answer, so:

You're not checking whether any state has changed since the
last GET to decide whether to recompute. That is the case in
which conditional GET would be appropriate. That would allow
you to avoid recomputing the page indefinitely as long as no
state changes necessitate it, but it requires that the clients
keep asking.


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.

Cheers, L. Dami

___
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/