[Catalyst] patch: C::P::Compress::Deflate

[Jonathan Rockway]

Right.  Think of it like this; your backend generates content, and your
frontend serves that content as if it were static.  Since you wouldn't
gzip your static HTML before serving it, it follows that your backend
server wouldn't compress it either.

Caching is a bit different.  I think it's best to do it on the frontend,
but if your frontend isn't smart enough to do it right (sessions), then
you'll have to let the backend do it.  Apache has some pretty
intelligent modules these days, though, so investigate those before you
do all the caching on the backend.  (Then there's memcached, which is
even farther back... but it serves a different purpose.)

Regards,
Jonathan Rockway

Perrin Harkins wrote:
> On Tue, 2006-09-19 at 15:00 -0500, Peter Karman wrote:
>> We have a typical proxy frontend/mod_perl backend setup. Which server should 
>> handle the compression? Seems like maybe the backend could, since we are caching 
>> pages, but don't know if there are accepted best practices on this.
> 
> If your frontend serves static files, and you want them compressed, you
> should put it there.  It's also better to have it there because it frees
> up the backend server processes faster.
> 
> - Perrin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 368 bytes
Desc: OpenPGP digital signature
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20060919/6d681a61/attachment.pgp