Re: Barrier to implementing web content compression in mod_perl

[Alex Greg <al...@gmail.com>]

On Mon, 31 Jan 2005 17:55:27 -0500, Perrin Harkins <pe...@elem.com> wrote:
> On Mon, 2005-01-31 at 21:23 +0000, Alex Greg wrote:
> > I'm using Apache::RegistryFilter:
> >
> > PerlHandler Apache::RegistryFilter Apache::Dynagzip
> >
> > See the attached httpd.conf for full context etc.
> 
> Does this actually work without the filitering?  I see a use of
> ScriptAlias in there, which usually sets mod-cgi and breaks mod_perl for
> that directory.

Yep, it runs fine. $ENV{'mod_perl'} is true.

http://perl.apache.org/docs/1.0/guide/config.html#Alias_Configurations
> 
> > Attached is my httpd.conf and a script test.cgi which reproduces the
> > problem I'm having. I'm using Apache/1.3.33 with mod_perl statically
> > linked.
> 
> This script should not need to call register_filter at all, since it's
> using Apache::RegistryFilter.

Apparently, if I don't call register_filter, then my script isn't
registered in the filter chain and Dynagzip then can't see my headers,
and it adds its own.

This would seem to be the case - if I comment out the $r =
$r->filter_register; line, I get this:

[root@server2 root]# (echo "GET /cgi-bin/test.cgi HTTP/1.1"; echo
"Host: 192.168.1.3"; echo) | nc 192.168.1.3 80
HTTP/1.1 200 OK
Date: Mon, 31 Jan 2005 23:03:52 GMT
Server: Apache/1.3.33 (Unix) mod_perl/1.29
X-Module-Sender: Apache::Dynagzip
Expires: Monday, 31-January-2005 23:08:52 GMT
Transfer-Encoding: chunked
Connection: close
Content-Type: text/html

ad
Content-type: text/html

<h1>Lorem Ipsum</h1>

<p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
Suspendisse fringilla porttitor mi....</p>


0


The first Content-Type: text/html header is from Dynagzip, the second
one is the one from my script. The error log repors

[Mon Jan 31 23:03:52 2005] [debug]
/usr/lib/perl5/site_perl/5.8.3/Apache/Dynagzip.pm(917): [client
192.168.1.3] Apache::Dynagzip default_content_handler creates default
Content-Type for GET /cgi-bin/test.cgi HTTP/1.1


Regards,


-- Alex

Re: Barrier to implementing web content compression in mod_perl

[Rob Mueller <ro...@fastmail.fm>]

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