Re: Barrier to implementing web content compression in mod_perl
- I'm surprised nobody has mentioned this yet on the list, but one approach
I'd recommend is going to 2 separate apache servers. A light frontend one
that does all the SSL/compression work, and a heavy backend mod_perl one.
This works fantastic for us, and avoids any of the issues of chained filters
in the mod_perl process. The light weight servers can easily do the
compression and SSL work and deal with clients on slow networks, leaving our
mod_perl servers to do the actual processing. Even though we process 2M+
requests a day, we generally don't have more than 20 mod_perl httpd procs at
any one time, while having 500-1000 frontend apache procs dealing with the
slow network clients.
We personally use mod_accel and mod_deflate written by Igor Sysoev. Although
most of the docs are in russian, we managed to get it working, and it's been
one of those things that has "just worked" since day 1. Anytime we've had
any technical issues, I've emailed Igor, and he's been fast and responsive
to reply and help, and he knows his stuff!
See the link at the bottom for our success story and compilation procedure.