Re: Barrier to implementing web content compression in mod_perl

[prev] [thread] [next] [Date index for 2005/02/01]

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.

http://modperlbook.org/html/ch12_01.html

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!

http://sysoev.ru/en/

See the link at the bottom for our success story and compilation procedure.

Good luck.

Rob