Loading ...
Sorry, an error occurred while loading the content.

Re: Barrier to implementing web content compression in mod_perl

Expand Messages
  • Rob Mueller
    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
    Message 1 of 9 , Feb 1, 2005
    • 0 Attachment
      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
    Your message has been successfully submitted and would be delivered to recipients shortly.