Re: [RFC] web-messaging application for mod_perl
On Mon, 30 Jun 2003 12:57:00 -0700 Adi Fairbank [EMAIL PROTECTED] wrote: Apache::WebMessaging I am about ready to release an intraserver web-messaging application for mod_perl. A brief description of the app follows; I'd like to hear some comments from the mod_perl/Perl/P5EE community on: You could look about Apache::* modules naming conventions: http://perl.apache.org/products/apache-modules.html#Module_Naming_Conventions Apache::App::WebMessaging namespace could be a right place :-) by - Enrico
Best compression for mod_perl application?
I used to use mod_gzip under Apache 1.3, and it worked great, saving my over 50% of my bandwidth for my mod_perl generated pages. But, it appears that mod_gzip doesn't work with Apache 2. Apache 2 has a built-in mod_deflate, but I've had some trouble with it (seemed to cause a load spike on my server + errors if I print ). I recall there used to be alternatives to mod_gzip out there, but I'm not sure if they apply to Apache 2. Are any of you use compression on your mod_perl pages? Do you recommend any compression schemes for the Apache 2/mp2 environment? TIA, -=bill
Re: Best compression for mod_perl application?
HI Bill, mod_gzip gave me a lot of grief when I used it - spurious errors kept filling the log and it didn't work easily with SSL. I spent a day trying to configure a nasty proxy solution. Apache::DynaGZIP has been much less hassle to install and run and it works with SSL. Although, I have not tried it on Apache 2. Kind Rehards, NIgel -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel:+44 (0) 207 987 5460 fax:+44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Re: Best compression for mod_perl application?
Apache::Dynagzip is not supposed to work on Apache-2. That would be of my real interest to know as many details of Bill's experience with mod_deflate as he can provide. Thanks, Slava - Original Message - From: Nigel Hamilton [EMAIL PROTECTED] To: Bill Marrs [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 9:56 AM Subject: Re: Best compression for mod_perl application? HI Bill, mod_gzip gave me a lot of grief when I used it - spurious errors kept filling the log and it didn't work easily with SSL. I spent a day trying to configure a nasty proxy solution. Apache::DynaGZIP has been much less hassle to install and run and it works with SSL. Although, I have not tried it on Apache 2. Kind Rehards, NIgel -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel: +44 (0) 207 987 5460 fax: +44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Re: Best compression for mod_perl application?
Hi Nigel, I had the same question three month ago. There are a few sources which compare the different modules. See mod_perl guide. My solution is now mod_deflate 1.0.18 with apache 1.3.27. My configuration in httpd.conf is: # activate compress IfModule mod_deflate.c # main switch DeflateEnable on DeflateMinLength1024 DeflateCompLevel8 # compress over proxies DeflateProxied on # switch off MSIE 4.x - has bugs DeflateDisableRange MSIE 4. # experimentell - for uploads DeflateVary on # DeflateHTTP 1.1 # default # activate for HTTP 1.0 DeflateHTTP 1.0 # DeflateTypestext/html # default # add more content types for compression DeflateTypestext/css DeflateTypestext/plain DeflateTypestext/rtf DeflateTypestext/xml DeflateTypestext/javascript DeflateTypesimage/vnd.dwg DeflateTypesimage/vnd.dxf DeflateTypesapplication/msword DeflateTypesapplication/vnd.hp-HPGL DeflateTypesapplication/vnd.ms-access DeflateTypesapplication/vnd.ms-excel DeflateTypesapplication/vnd.ms-powerpoint DeflateTypesapplication/vnd.ms-project DeflateTypesapplication/vnd.visio DeflateTypesapplication/x-javascript # pdf does no work # DeflateTypesapplication/pdf /IfModule I hope that helps you. Regards, Sven. Am Die, 2003-07-01 um 17.02 schrieb Slava Bizyayev: Apache::Dynagzip is not supposed to work on Apache-2. That would be of my real interest to know as many details of Bill's experience with mod_deflate as he can provide. Thanks, Slava - Original Message - From: Nigel Hamilton [EMAIL PROTECTED] To: Bill Marrs [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 9:56 AM Subject: Re: Best compression for mod_perl application? HI Bill, mod_gzip gave me a lot of grief when I used it - spurious errors kept filling the log and it didn't work easily with SSL. I spent a day trying to configure a nasty proxy solution. Apache::DynaGZIP has been much less hassle to install and run and it works with SSL. Although, I have not tried it on Apache 2. Kind Rehards, NIgel -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel: +44 (0) 207 987 5460 fax: +44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Re: A::Registry vs. mod_perl handler philosophy
On Fri, 2003-06-20 at 12:18, Peter B. Ensch wrote: It's been suggested to me that content generating apps should be done under A::R, whereas logging, authentication Etc. should be implemented as mod_perl handlers. What is the opinion of the group? I'm late to the party, but here's an old post of mine that sums up my opinion: http://marc.theaimsgroup.com/?l=apache-modperlm=95440118003848w=2 - Perrin
Re: Best compression for mod_perl application?
And how about http://devl4.outlook.net/devdoc/FAQ/compression.html for Apache 1.3.27? ;-) Slava - Original Message - From: Sven Geisler [EMAIL PROTECTED] To: Nigel Hamilton [EMAIL PROTECTED]; Slava Bizyayev [EMAIL PROTECTED] Cc: Bill Marrs [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 10:48 AM Subject: Re: Best compression for mod_perl application? Hi Nigel, I had the same question three month ago. There are a few sources which compare the different modules. See mod_perl guide. My solution is now mod_deflate 1.0.18 with apache 1.3.27. My configuration in httpd.conf is: # activate compress IfModule mod_deflate.c # main switch DeflateEnable on DeflateMinLength1024 DeflateCompLevel8 # compress over proxies DeflateProxied on # switch off MSIE 4.x - has bugs DeflateDisableRange MSIE 4. # experimentell - for uploads DeflateVary on # DeflateHTTP 1.1 # default # activate for HTTP 1.0 DeflateHTTP 1.0 # DeflateTypestext/html # default # add more content types for compression DeflateTypestext/css DeflateTypestext/plain DeflateTypestext/rtf DeflateTypestext/xml DeflateTypestext/javascript DeflateTypesimage/vnd.dwg DeflateTypesimage/vnd.dxf DeflateTypesapplication/msword DeflateTypesapplication/vnd.hp-HPGL DeflateTypesapplication/vnd.ms-access DeflateTypesapplication/vnd.ms-excel DeflateTypesapplication/vnd.ms-powerpoint DeflateTypesapplication/vnd.ms-project DeflateTypesapplication/vnd.visio DeflateTypesapplication/x-javascript # pdf does no work # DeflateTypesapplication/pdf /IfModule I hope that helps you. Regards, Sven. Am Die, 2003-07-01 um 17.02 schrieb Slava Bizyayev: Apache::Dynagzip is not supposed to work on Apache-2. That would be of my real interest to know as many details of Bill's experience with mod_deflate as he can provide. Thanks, Slava - Original Message - From: Nigel Hamilton [EMAIL PROTECTED] To: Bill Marrs [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 9:56 AM Subject: Re: Best compression for mod_perl application? HI Bill, mod_gzip gave me a lot of grief when I used it - spurious errors kept filling the log and it didn't work easily with SSL. I spent a day trying to configure a nasty proxy solution. Apache::DynaGZIP has been much less hassle to install and run and it works with SSL. Although, I have not tried it on Apache 2. Kind Rehards, NIgel -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel: +44 (0) 207 987 5460 fax: +44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Re: [RFC] web-messaging application for mod_perl
On, or in the near vicinity of Tue, 1 Jul 2003 11:23:00 +0200 Enrico Sorcinelli [EMAIL PROTECTED] has thus spoken: On Mon, 30 Jun 2003 12:57:00 -0700 Adi Fairbank [EMAIL PROTECTED] wrote: Apache::WebMessaging I am about ready to release an intraserver web-messaging application for mod_perl. A brief description of the app follows; I'd like to hear some comments from the mod_perl/Perl/P5EE community on: You could look about Apache::* modules naming conventions: http://perl.apache.org/products/apache-modules.html#Module_Naming_Conventions Apache::App::WebMessaging namespace could be a right place :-) According to the asterisk note below Apache::App:: However, if you are planning a substantial framework with many inter-related modules, you should probably go with a top-level namespace outside of Apache::. This app already has 7-8 inter-related modules, though I would not call it a substantial framework. In fact it requires you to already have your own application framework setup in order to use it. It's basically a plug-in application for your existing mod_perl framework. I could rename it to just WebMessaging:: but it is specifically designed for mod_perl, which is why I think it should go in Apache::. Also, I noticed there are currently no Apache::App:: modules. Should this be the first?? -Adi
Re: Sharing memory between children
On Mon, 2003-06-16 at 07:12, Clinton Gormley wrote: I had a look at the memory usage of my apache/mod_perl 1 processes, and was alarmed to find that only 3Mb of 25Mb processes was being shared (and that's straight after startup) I have gone to great lengths to (1) Preload modules in my startup file (2) Load shared config data during server startup so that that info can also be shared Is it possible that the modules you're using do a lot of work after the compile phase? For example, if they use autoloading or pull in a lot of other modules conditionally later on with require statements that will result in things being compiled after startup and thus not shared. You amount of shared memory seems very low to me, so I think there's something that these modules are doing that is working against sharing. - Perrin
Re: Best compression for mod_perl application?
This is one of the source I had in mind. Well done Slava. BTW. Do you consider the latest version of mod_deflate? Regardsm Sven. Am Die, 2003-07-01 um 18.12 schrieb Slava Bizyayev: And how about http://devl4.outlook.net/devdoc/FAQ/compression.html for Apache 1.3.27? ;-) Slava - Original Message - From: Sven Geisler [EMAIL PROTECTED] To: Nigel Hamilton [EMAIL PROTECTED]; Slava Bizyayev [EMAIL PROTECTED] Cc: Bill Marrs [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 10:48 AM Subject: Re: Best compression for mod_perl application? Hi Nigel, I had the same question three month ago. There are a few sources which compare the different modules. See mod_perl guide. My solution is now mod_deflate 1.0.18 with apache 1.3.27. My configuration in httpd.conf is: # activate compress IfModule mod_deflate.c # main switch DeflateEnable on DeflateMinLength1024 DeflateCompLevel8 # compress over proxies DeflateProxied on # switch off MSIE 4.x - has bugs DeflateDisableRange MSIE 4. # experimentell - for uploads DeflateVary on # DeflateHTTP 1.1 # default # activate for HTTP 1.0 DeflateHTTP 1.0 # DeflateTypestext/html # default # add more content types for compression DeflateTypestext/css DeflateTypestext/plain DeflateTypestext/rtf DeflateTypestext/xml DeflateTypestext/javascript DeflateTypesimage/vnd.dwg DeflateTypesimage/vnd.dxf DeflateTypesapplication/msword DeflateTypesapplication/vnd.hp-HPGL DeflateTypesapplication/vnd.ms-access DeflateTypesapplication/vnd.ms-excel DeflateTypesapplication/vnd.ms-powerpoint DeflateTypesapplication/vnd.ms-project DeflateTypesapplication/vnd.visio DeflateTypesapplication/x-javascript # pdf does no work # DeflateTypesapplication/pdf /IfModule I hope that helps you. Regards, Sven. Am Die, 2003-07-01 um 17.02 schrieb Slava Bizyayev: Apache::Dynagzip is not supposed to work on Apache-2. That would be of my real interest to know as many details of Bill's experience with mod_deflate as he can provide. Thanks, Slava - Original Message - From: Nigel Hamilton [EMAIL PROTECTED] To: Bill Marrs [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 9:56 AM Subject: Re: Best compression for mod_perl application? HI Bill, mod_gzip gave me a lot of grief when I used it - spurious errors kept filling the log and it didn't work easily with SSL. I spent a day trying to configure a nasty proxy solution. Apache::DynaGZIP has been much less hassle to install and run and it works with SSL. Although, I have not tried it on Apache 2. Kind Rehards, NIgel -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel: +44 (0) 207 987 5460 fax: +44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Apache::Request for CGI? (was: Re: A::Registry vs. mod_perl handler philosophy)
Perrin Harkins [EMAIL PROTECTED] writes: [...] I'm late to the party, but here's an old post of mine that sums up my opinion: http://marc.theaimsgroup.com/?l=apache-modperlm=95440118003848w=2 +1. Scripting _inside_ the server opens up possibilities that are unimaginable to folks who are content confining themselves to the lowest common denominator (CGI). That said, apreq-dev is looking for someone to adopt and develop the CGI port of libapreq-2/Apache::Request. I'm shooting for a developer release of libapreq-2 before OSCON, and it'd be _really_ cool if we had a functional CGI port available. -- Joe Schaefer
advice on implementing a controller manager
I am writing an application following MVC with Perl Apache modules and the Template Toolkit. Apache is 1.x. I would like to have just one entry point to the application, which would play the role of someone who sets everything necessary up and forwards the actual request to a selected handler. From what I have read, looks like implementing that controller as a PerlFixupHandler which would use push_handlers() and pass things via pnotes() would be fine, but I am not experienced in mod_perl. Would you suggest a different approach? fxn -- s;$;Barcelona Perl Mongers;;$/=$||gaudi||3;map$,+=(split//)*(-1)**$|++, (split)[.11_09,1.714];$.=$!!~m~erce~;$=y~catalunya~~,$;=y~rambles~~,$* =$/^$.;$:=$.+length,[EMAIL PROTECTED]/**$*%$:,$%=$/*$-$*;print+chr($_0xA?$. .$[$_:m:^$.:?$.$_:$_)for($**($**$%-$//$/),$%-$*,$,*$/,$***$***$*,$* **$,,$[EMAIL PROTECTED]/,$**$,,$;,$***$***$*,$***$*,$.,$**$,$***$,,$***$***$** $,,$.,$*$*,$+$.,$***$,,$,-$.,$[EMAIL PROTECTED]/,$;*$/**$*,$,$.,[EMAIL PROTECTED])
Re: Best compression for mod_perl application?
Thanks Sven, From my current point of view mod_deflate for Apache-2 should be still considered in experimental stage. That's why I so interested to collect as much user experience with mod_deflate-2 as possible. Thanks, Slava - Original Message - From: Sven Geisler [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: Nigel Hamilton [EMAIL PROTECTED]; Bill Marrs [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 11:21 AM Subject: Re: Best compression for mod_perl application? This is one of the source I had in mind. Well done Slava. BTW. Do you consider the latest version of mod_deflate? Regardsm Sven. Am Die, 2003-07-01 um 18.12 schrieb Slava Bizyayev: And how about http://devl4.outlook.net/devdoc/FAQ/compression.html for Apache 1.3.27? ;-) Slava - Original Message - From: Sven Geisler [EMAIL PROTECTED] To: Nigel Hamilton [EMAIL PROTECTED]; Slava Bizyayev [EMAIL PROTECTED] Cc: Bill Marrs [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 10:48 AM Subject: Re: Best compression for mod_perl application? Hi Nigel, I had the same question three month ago. There are a few sources which compare the different modules. See mod_perl guide. My solution is now mod_deflate 1.0.18 with apache 1.3.27. My configuration in httpd.conf is: # activate compress IfModule mod_deflate.c # main switch DeflateEnable on DeflateMinLength1024 DeflateCompLevel8 # compress over proxies DeflateProxied on # switch off MSIE 4.x - has bugs DeflateDisableRange MSIE 4. # experimentell - for uploads DeflateVary on # DeflateHTTP 1.1 # default # activate for HTTP 1.0 DeflateHTTP 1.0 # DeflateTypestext/html # default # add more content types for compression DeflateTypestext/css DeflateTypestext/plain DeflateTypestext/rtf DeflateTypestext/xml DeflateTypestext/javascript DeflateTypesimage/vnd.dwg DeflateTypesimage/vnd.dxf DeflateTypesapplication/msword DeflateTypesapplication/vnd.hp-HPGL DeflateTypesapplication/vnd.ms-access DeflateTypesapplication/vnd.ms-excel DeflateTypesapplication/vnd.ms-powerpoint DeflateTypesapplication/vnd.ms-project DeflateTypesapplication/vnd.visio DeflateTypesapplication/x-javascript # pdf does no work # DeflateTypesapplication/pdf /IfModule I hope that helps you. Regards, Sven. Am Die, 2003-07-01 um 17.02 schrieb Slava Bizyayev: Apache::Dynagzip is not supposed to work on Apache-2. That would be of my real interest to know as many details of Bill's experience with mod_deflate as he can provide. Thanks, Slava - Original Message - From: Nigel Hamilton [EMAIL PROTECTED] To: Bill Marrs [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 9:56 AM Subject: Re: Best compression for mod_perl application? HI Bill, mod_gzip gave me a lot of grief when I used it - spurious errors kept filling the log and it didn't work easily with SSL. I spent a day trying to configure a nasty proxy solution. Apache::DynaGZIP has been much less hassle to install and run and it works with SSL. Although, I have not tried it on Apache 2. Kind Rehards, NIgel -- Nigel Hamilton Turbo10 Metasearch Engine email: [EMAIL PROTECTED] tel: +44 (0) 207 987 5460 fax: +44 (0) 207 987 5468 http://turbo10.com Search Deeper. Browse Faster.
Re: advice on implementing a controller manager
Xavier Noria wrote: I am writing an application following MVC with Perl Apache modules and the Template Toolkit. Apache is 1.x. I would like to have just one entry point to the application, which would play the role of someone who sets everything necessary up and forwards the actual request to a selected handler. From what I have read, looks like implementing that controller as a PerlFixupHandler which would use push_handlers() and pass things via pnotes() would be fine, but I am not experienced in mod_perl. Would you suggest a different approach? A word of advice: if you'd like to use it under different web environments, create your own system for registering/calling handlers instead of using the Apache API. That is, have a map of URL-to-class and have your controller find the class to execute based on the URL and call it directly. This is how OpenInteract does it and it's saved quite a lot of grief. It also makes for nice decoupling which is always a good thing. Of course, you could use OpenInteract as an MVC framework that uses the Template Toolkit, but that's a different matter... :-) Chris -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Content compression FAQ
It should not be considered a bugfix anymore. It is NOT required to do, because that particular story with M$IE is over. Recently, there were some problems with M$IE reported, namely a partially lost compressed content when using SSL over HTTP/1.1. It happens infrequently. The problem remains in research stage to date. It seems to be NOT a problem of compression: the problem is effectively addressed through downgrade of HTTP/1.1 to HTTP/1.0 over SSL for this browser. Then the response could be sent back compressed over HTTP/1.0. It works fine. Thanks, Slava - Original Message - From: David Dick [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, June 14, 2003 5:20 PM Subject: Re: How practical is that Practical mod_perl? or, as a bugfix for future versions of mod_perl compression modules, before compressing the page, the module should provide the option of adding 2048 bytes of spaces to the beginning of the page, which according to my quick calculations, gzips down to 46 bytes? only for ie6 of course. :) Slava Bizyayev wrote: gzip problem in IE6 http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496 is over since 1. M$ provides a free patch; 2. those lazy users (who usually don't care to apply patches) are not able to report problems anymore. Personally, I would recommend not to deal with deflate when possible.
Re: Best compression for mod_perl application?
That would be of my real interest to know as many details of Bill's
experience with mod_deflate as he can provide.
Since I posted my first message, I've been snooping around the 'net to find
more info on mod_gzip and mod_deflate. Here's what I came up with:
The general recommendation seems to be migration from mod_gzip to
mod_deflate when you switch to Apache 2.0. mod_gzip seems to have lost
most of its support going forward while mod_deflate is part of the Apache
source code and has active development.
There is a Apache 2.0 compatible version of mod_gzip, here:
http://www.gknw.de/development/apache/httpd-2.0/unix/modules/
When I tried it, it didn't work for me. It caused my site to spit out
blank pages and garbage. I had used my old Apache 1.3 mod_gzip config with
it. I read that there's some odd timing issues where the Apache 2.0
version of mod_gzip branched a long time ago and thus doesn't have some of
the modern mod_gzip 1.3.x features. I didn't get config errors, though,
just blanks and garbage. So, I decided to back away slowly for mod_gzip on
Apache 2.0. There is more discussion of it here:
http://freshmeat.net/projects/mod_gzip/?topic_id=90
There a good mod_gzip info page here, though little is said about a 2.0
version:
http://www.schroepl.net/projekte/mod_gzip/index.htm
The mod_gzip mailing list has some good info. Here's a 26 Jun 2003 post by
someone who seems to know well what's going on (I think the author of the
above page):
Subject: [Mod_gzip] gzip vs deflate on Apache
http://lists.over.net/pipermail/mod_gzip/2003-June/007130.html
So, I decided to try harder to move ahead with mod_deflate. I'm using a
built from scratch, Apache/2.0.46 mod_perl_1.99_09. Work is being done on
mod_deflate, some recent directives has been added (I hear). One of which
is DeflateCompressionLevel. Along with this addition in 2.0.44 came a
better default for this compression level. It's now 6, the same thing that
gzip and zlib uses by default. Apparently, it had been 1 before that,
which is fast but doesn't compress very well. There's some discussion of
this here:
http://www.webcompression.org/deflate-compress.html
My own personal experience with mod_deflate (in Apache/2.0.46) is that it
tends to spike my server's load. My server (gametz.com) is dual 800Mhz,
1.5GB ram, Linux, doing about 70K pages/day. Last night, I happened to be
watching it while the load jumped up a few points during my site's prime
time, so I pulled mod_deflate out of the config file and that fixed it.
So, today, I'm trying a lower DeflateCompressionLevel. I'm using 4 now
(instead of the default 6). This seems better, though the load is still a
little higher than it should be and I'm not quote at prime time
yet. Still, I am getting decent compression. I'm going to keep an eye on
it, I suspect I'll be at 3 later this evening.
I never had any trouble with load when I used mod_gzip and Apache 1.3.
The other odd problem I got was that if anywhere in my perl code I printed
nothing (e.g. print or $foo=;print $foo), I'd get this error:
error: 20014:Error string not specified yet at /my/perl/code.pl line 123
This error was both blurted to the error_log and to the web page (screwing
up the page and truncating further output).
I changed my code to print instead of (HTML ignores extra
white-space, so no biggie), and the errors all went away. So, I see this
as an annoyance more than a serious bug.
I really should try to tell the author of mod_deflate about these problems.
Here's the config I'm using for mod_deflate:
#
## Deflate
#
LoadModule deflate_module modules/mod_deflate.so
AddOutputFilterByType DEFLATE text/*
SetOutputFilter DEFLATE
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
DeflateBufferSize 8096
# DeflateCompressionLevel 6
DeflateCompressionLevel 4
DeflateMemLevel 9
DeflateWindowSize 15
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '%r %{outstream}n/%{instream}n (%{ratio}n%%) %{User-agent}i'
defl\
ate
CustomLog /var/log/httpd/deflate_log deflate
All of which I cribbed from the Apache 2.0 manual:
http://httpd.apache.org/docs-2.0/mod/mod_deflate.html
I sort of got forced into upgrading to Apache 2.0/mp2/etc. by RedHat. They
announced they would pull support for old releases (all that used Apache
1.3) by the end of the year. Apparently, this may be an intentional
(evil?) business move by them to motivate more customers to move to their
Enterprise OS (which is very expensive, but has more stable software like
good old Apache 1.3 mp1).
I did try to go back at one point, builing Apache 1.3 from source, but it
had some other problem (maybe, because I used Perl 5.8.0?). But, then I
waffled and decided there's also a lot of value in staying current. So,
I'm back to 2.0 land, and I'm surviving so far.
-=bill
Re: Best compression for mod_perl application?
Hi Bill,
Thanks for taking the time to post your experiences.
It's a shame that so much time is spent tweaking, compiling,
testing, ferretting for bug references.
On Tue, 1 Jul 2003, Bill Marrs wrote:
That would be of my real interest to know as many details of Bill's
experience with mod_deflate as he can provide.
Since I posted my first message, I've been snooping around the 'net to find
more info on mod_gzip and mod_deflate. Here's what I came up with:
The general recommendation seems to be migration from mod_gzip to
mod_deflate when you switch to Apache 2.0. mod_gzip seems to have lost
most of its support going forward while mod_deflate is part of the Apache
source code and has active development.
There is a Apache 2.0 compatible version of mod_gzip, here:
http://www.gknw.de/development/apache/httpd-2.0/unix/modules/
When I tried it, it didn't work for me. It caused my site to spit out
blank pages and garbage. I had used my old Apache 1.3 mod_gzip config with
it. I read that there's some odd timing issues where the Apache 2.0
version of mod_gzip branched a long time ago and thus doesn't have some of
the modern mod_gzip 1.3.x features. I didn't get config errors, though,
just blanks and garbage. So, I decided to back away slowly for mod_gzip on
Apache 2.0. There is more discussion of it here:
http://freshmeat.net/projects/mod_gzip/?topic_id=90
There a good mod_gzip info page here, though little is said about a 2.0
version:
http://www.schroepl.net/projekte/mod_gzip/index.htm
The mod_gzip mailing list has some good info. Here's a 26 Jun 2003 post by
someone who seems to know well what's going on (I think the author of the
above page):
Subject: [Mod_gzip] gzip vs deflate on Apache
http://lists.over.net/pipermail/mod_gzip/2003-June/007130.html
So, I decided to try harder to move ahead with mod_deflate. I'm using a
built from scratch, Apache/2.0.46 mod_perl_1.99_09. Work is being done on
mod_deflate, some recent directives has been added (I hear). One of which
is DeflateCompressionLevel. Along with this addition in 2.0.44 came a
better default for this compression level. It's now 6, the same thing that
gzip and zlib uses by default. Apparently, it had been 1 before that,
which is fast but doesn't compress very well. There's some discussion of
this here:
http://www.webcompression.org/deflate-compress.html
My own personal experience with mod_deflate (in Apache/2.0.46) is that it
tends to spike my server's load. My server (gametz.com) is dual 800Mhz,
1.5GB ram, Linux, doing about 70K pages/day. Last night, I happened to be
watching it while the load jumped up a few points during my site's prime
time, so I pulled mod_deflate out of the config file and that fixed it.
So, today, I'm trying a lower DeflateCompressionLevel. I'm using 4 now
(instead of the default 6). This seems better, though the load is still a
little higher than it should be and I'm not quote at prime time
yet. Still, I am getting decent compression. I'm going to keep an eye on
it, I suspect I'll be at 3 later this evening.
I never had any trouble with load when I used mod_gzip and Apache 1.3.
The other odd problem I got was that if anywhere in my perl code I printed
nothing (e.g. print or $foo=;print $foo), I'd get this error:
error: 20014:Error string not specified yet at /my/perl/code.pl line 123
This error was both blurted to the error_log and to the web page (screwing
up the page and truncating further output).
I changed my code to print instead of (HTML ignores extra
white-space, so no biggie), and the errors all went away. So, I see this
as an annoyance more than a serious bug.
I really should try to tell the author of mod_deflate about these problems.
Here's the config I'm using for mod_deflate:
#
## Deflate
#
LoadModule deflate_module modules/mod_deflate.so
AddOutputFilterByType DEFLATE text/*
SetOutputFilter DEFLATE
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
DeflateBufferSize 8096
# DeflateCompressionLevel 6
DeflateCompressionLevel 4
DeflateMemLevel 9
DeflateWindowSize 15
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '%r %{outstream}n/%{instream}n (%{ratio}n%%) %{User-agent}i'
defl\
ate
CustomLog /var/log/httpd/deflate_log deflate
All of which I cribbed from the Apache 2.0 manual:
http://httpd.apache.org/docs-2.0/mod/mod_deflate.html
I sort of got forced into upgrading to Apache 2.0/mp2/etc. by RedHat. They
announced they would pull support for old releases (all that used Apache
1.3) by the end of the year. Apparently, this may be an intentional
(evil?) business move by them to motivate more customers to move to their
Enterprise OS (which is very expensive, but has more stable software like
good
Re: Best compression for mod_perl application?
The other odd problem I got was that if anywhere in my perl code I printed nothing (e.g. print or $foo=;print $foo), I'd get this error: error: 20014:Error string not specified yet at /my/perl/code.pl line 123 This error was both blurted to the error_log and to the web page (screwing up the page and truncating further output). I changed my code to print instead of (HTML ignores extra white-space, so no biggie), and the errors all went away. So, I see this as an annoyance more than a serious bug. if you're using mod_perl for your perl script, it might be a mod_perl issue an not mod_deflate - try the same from a mod_cgi script and see if it has the same problem. if not, we probably need to dig around mod_perl core for a fix. --Geoff
Re: Best compression for mod_perl application?
Hi Bill,
Thank you very much for the story. It makes sense. Just a couple of
questions:
1. Are you using any Cascaded Stile Sheets and/of JavaScript libraries
linked to your main web pages?
2. If yes, how do you turn compression off for those files in case of
Netscape-4 originated request?
Thanks,
Slava
- Original Message -
From: Bill Marrs [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, July 01, 2003 2:33 PM
Subject: Re: Best compression for mod_perl application?
That would be of my real interest to know as many details of Bill's
experience with mod_deflate as he can provide.
Since I posted my first message, I've been snooping around the 'net to
find
more info on mod_gzip and mod_deflate. Here's what I came up with:
The general recommendation seems to be migration from mod_gzip to
mod_deflate when you switch to Apache 2.0. mod_gzip seems to have lost
most of its support going forward while mod_deflate is part of the Apache
source code and has active development.
There is a Apache 2.0 compatible version of mod_gzip, here:
http://www.gknw.de/development/apache/httpd-2.0/unix/modules/
When I tried it, it didn't work for me. It caused my site to spit out
blank pages and garbage. I had used my old Apache 1.3 mod_gzip config
with
it. I read that there's some odd timing issues where the Apache 2.0
version of mod_gzip branched a long time ago and thus doesn't have some of
the modern mod_gzip 1.3.x features. I didn't get config errors, though,
just blanks and garbage. So, I decided to back away slowly for mod_gzip
on
Apache 2.0. There is more discussion of it here:
http://freshmeat.net/projects/mod_gzip/?topic_id=90
There a good mod_gzip info page here, though little is said about a 2.0
version:
http://www.schroepl.net/projekte/mod_gzip/index.htm
The mod_gzip mailing list has some good info. Here's a 26 Jun 2003 post
by
someone who seems to know well what's going on (I think the author of the
above page):
Subject: [Mod_gzip] gzip vs deflate on Apache
http://lists.over.net/pipermail/mod_gzip/2003-June/007130.html
So, I decided to try harder to move ahead with mod_deflate. I'm using a
built from scratch, Apache/2.0.46 mod_perl_1.99_09. Work is being done on
mod_deflate, some recent directives has been added (I hear). One of which
is DeflateCompressionLevel. Along with this addition in 2.0.44 came a
better default for this compression level. It's now 6, the same thing
that
gzip and zlib uses by default. Apparently, it had been 1 before that,
which is fast but doesn't compress very well. There's some discussion of
this here:
http://www.webcompression.org/deflate-compress.html
My own personal experience with mod_deflate (in Apache/2.0.46) is that it
tends to spike my server's load. My server (gametz.com) is dual 800Mhz,
1.5GB ram, Linux, doing about 70K pages/day. Last night, I happened to be
watching it while the load jumped up a few points during my site's prime
time, so I pulled mod_deflate out of the config file and that fixed it.
So, today, I'm trying a lower DeflateCompressionLevel. I'm using 4 now
(instead of the default 6). This seems better, though the load is still a
little higher than it should be and I'm not quote at prime time
yet. Still, I am getting decent compression. I'm going to keep an eye on
it, I suspect I'll be at 3 later this evening.
I never had any trouble with load when I used mod_gzip and Apache 1.3.
The other odd problem I got was that if anywhere in my perl code I printed
nothing (e.g. print or $foo=;print $foo), I'd get this error:
error: 20014:Error string not specified yet at /my/perl/code.pl line 123
This error was both blurted to the error_log and to the web page (screwing
up the page and truncating further output).
I changed my code to print instead of (HTML ignores extra
white-space, so no biggie), and the errors all went away. So, I see this
as an annoyance more than a serious bug.
I really should try to tell the author of mod_deflate about these
problems.
Here's the config I'm using for mod_deflate:
#
## Deflate
#
LoadModule deflate_module modules/mod_deflate.so
AddOutputFilterByType DEFLATE text/*
SetOutputFilter DEFLATE
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
DeflateBufferSize 8096
# DeflateCompressionLevel 6
DeflateCompressionLevel 4
DeflateMemLevel 9
DeflateWindowSize 15
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '%r %{outstream}n/%{instream}n (%{ratio}n%%) %{User-agent}i'
defl\
ate
CustomLog /var/log/httpd/deflate_log deflate
All of which I cribbed from the Apache 2.0 manual:
http://httpd.apache.org/docs-2.0/mod/mod_deflate.html
I sort of got forced into upgrading to Apache 2.0/mp2/etc. by RedHat.
They
announced they would pull support for old releases (all that used Apache
1.3) by the end of the
Re: Best compression for mod_perl application?
1. Are you using any Cascaded Stile Sheets and/of JavaScript libraries linked to your main web pages? I'm not, but... I think mod_defalte's hook is after all that is processed, so it's not especially relevant. 2. If yes, how do you turn compression off for those files in case of Netscape-4 originated request? http://httpd.apache.org/docs-2.0/mod/mod_deflate.html says to use this sort of thing: # Netscape 4.x has some problems... BrowserMatch ^Mozilla/4 gzip-only-text/html # Netscape 4.06-4.08 have some more problems BrowserMatch ^Mozilla/4\.0[678] no-gzip # MSIE masquerades as Netscape, but it is fine BrowserMatch \bMSIE !no-gzip !gzip-only-text/html # Don't compress images SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary # Make sure proxies don't deliver the wrong content Header append Vary User-Agent env=!dont-vary
Re: Content compression FAQ
Slava Bizyayev wrote: It should not be considered a bugfix anymore. It is NOT required to do, because that particular story with M$IE is over. Sounds like we agree to disagree on this one. My opinion would be, if there is a known problem with a browser version that can be solved with a minimum amount of disruption to other users, then it's worth doing. For me, the prospect of adding at most 46 bytes to a compressed response is worth it. For people who need every last bit of bandwidth performance, it may not be. Hence, the bugfix should be optional. I understand that microsoft have a patch for the problem, the issue is how many people actually are using the patch? Probably the vast majority to be sure, but there ain't no way of telling. or, as a bugfix for future versions of mod_perl compression modules, before compressing the page, the module should provide the option of adding 2048 bytes of spaces to the beginning of the page, which according to my quick calculations, gzips down to 46 bytes? only for ie6 of course. :) Slava Bizyayev wrote: gzip problem in IE6 http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312496 is over since 1. M$ provides a free patch; 2. those lazy users (who usually don't care to apply patches) are not able to report problems anymore.
Re: Best compression for mod_perl application?
It's amazing! The flow control system is definitely sufficient. Ian Holsman really developed a very good module. The rest is up to accomplishing filters those supposed to be simple and specific. Those minor bug with optional empty chunk in the middle of the body should be easy to fix. Thanks, Slava - Original Message - From: Bill Marrs [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Sent: Tuesday, July 01, 2003 3:33 PM Subject: Re: Best compression for mod_perl application? 1. Are you using any Cascaded Stile Sheets and/of JavaScript libraries linked to your main web pages? I'm not, but... I think mod_defalte's hook is after all that is processed, so it's not especially relevant. 2. If yes, how do you turn compression off for those files in case of Netscape-4 originated request? http://httpd.apache.org/docs-2.0/mod/mod_deflate.html says to use this sort of thing: # Netscape 4.x has some problems... BrowserMatch ^Mozilla/4 gzip-only-text/html # Netscape 4.06-4.08 have some more problems BrowserMatch ^Mozilla/4\.0[678] no-gzip # MSIE masquerades as Netscape, but it is fine BrowserMatch \bMSIE !no-gzip !gzip-only-text/html # Don't compress images SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary # Make sure proxies don't deliver the wrong content Header append Vary User-Agent env=!dont-vary
Detecting graceful restart
Hello, Does anyone know if it's possible to hook into Apache graceful restarts? I tried PerlRestartHandler, but it doesn't seem to get called. I see it called when I do apachectl startssl, but not apachectl restart nor apachectl graceful. None of the documentation I've found mentions wheter it gets called only for plain restarts or for graceful restarts also. Thanks! __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
RE: advice on implementing a controller manager
Hi Chris -- A word of advice: if you'd like to use it under different web environments, create your own system for registering/calling handlers instead of using the Apache API. That is, have a map of URL-to-class and have your controller find the class to execute based on the URL and call it directly. This is how OpenInteract does it and it's saved quite a lot of grief. It also makes for nice decoupling which is always a good thing. If you want a unique URL which points to a particular perl class, you could also use CGI::Application. It was built to run under mod_perl, and solve exactly this problem. TTYL, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
Re: Detecting graceful restart - wacky $$
Never mind. It was a mistake on my part. I was setting it with push_handler() in my startup.pl, so of course it didn't persist. Once I switched to setting it in the httpd.conf it was called on every restart, graceful or not. Now I'm having a different problem. In my restart handler I print out the PID using a simple 'warn pid = $$\n. I was expecting it would print out the PID of the parent (listener) Apache process, but the PID that is printed does not exist in the process table, and is in fact the real Apache parent PID - 1. Getting the PID with POSIX::getpid produces the same result. I'm baffled by this. Can anyone shed any light? Javier wrote: Hello, Does anyone know if it's possible to hook into Apache graceful restarts? I tried PerlRestartHandler, but it doesn't seem to get called. I see it called when I do apachectl startssl, but not apachectl restart nor apachectl graceful. None of the documentation I've found mentions wheter it gets called only for plain restarts or for graceful restarts also. Thanks! __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Re: Detecting graceful restart - wacky $$
Javier Now I'm having a different problem. In my restart handler I Javier print out the PID using a simple 'warn pid = $$\n. I was Javier expecting it would print out the PID of the parent Javier (listener) Apache process [...] Sounds like you want getppid() instead. b. -- /* Bruno Connelly, [EMAIL PROTECTED] */
