HI Adam,
Your speed vs time point is a good one. If the network is fast
then the time it takes the CPU to do the compression may negate any speed
benefits from compressing the message.
However, compression is generally worth it because:
* HTML compresses well - messages often compress by 80% or more.
* Even though your network may be fast - the last mile over a 28.8 K
modem can be slow - and compression helps here
* The CPU cost of calculating the compression can be avoiding by caching
the compressed document in memory or on disk
On a side note ... I've had a tough time trying to get all the
compression bits and pieces to work together.
I've tried mod_gzip and it worked well for non-SSL content ...
however, it didn't work with SSL and the only workaround is proxying to a
second server ... and I couldn't get this to work with mod_perl. :-(
I then looked at mod_deflate but unfortunately this involved
re-compiling the Apache source and applying patches etc.
Recently I've installed Apache:DynaGzip ... which installed no
problem.
Apache::DynaGzip, is supposed to work with SSL and can handle
chunked dynamic output .... which is what I'm looking for - I haven't set
this up yet but will report my experiences back to the list.
NIgel
> I feel like most of my responses on this list ask 'why' rather than
> answer a question but:
>
> Assuming you have an internet connection between 1 Mb and 10 Mb
>
> You're internal network is running at 100Mb with 1Gb around the corner
> or already going.
>
> Why bother compressing stuff when it seems clear that processing power
> is more of a bottleneck than bandwidth (because in the end, compression
> is always a tradeoff between computation and the quantity of information
> coming to/going out of your machine).
>
> I would have to imagine that compression would only speed up the actual
> response time if the external connection is >25% (just a guess) of the
> internal speed limit. So, in a typical 100Mb internal network, I
> wouldn't worry about compression unless I could actually deliver 25Mb to
> the end-user. Of course, if we're paying for more than a 25Mb
> (10k/month?) connection to the internet, than the cost of a 1Gb network
> is nominal.
>
> All this is moot if the app serves a lan, but still, I think the
> gzipping would simply make the application more sluggish rather than
> speed it up (I concede that I have not done any benchmarks) since
> internal network bandwidth is so cheap.
>
> Adam
>
>
> -----Original Message-----
> From: Nigel Hamilton [mailto:nigel@;turbo10.com]
> Sent: Friday, October 18, 2002 10:47 PM
> To: [EMAIL PROTECTED]
> Subject: SSL <-> mod_gzip <-> mod_perl = mod_proxy error
>
>
> Hi,
>
> I'm trying to hand all SSL requests to a backend mod_perl server
>
> with mod_gzip installed for compression.
>
> This means that SSL content is pre-compressed by the backend
> server before being encrypted by the frontend (Mini How To - below).
>
> Apparently mod_gzip and SSL on the same server will not work -
> this is why I need to pass the request to a proxy to handle the
> compression.
>
> So ... a request on https://turbo10.com:446/index.html (server
> A)
> passes to http://turbo10.com:44300/index.html (server B).
>
> The file is compressed by server B and passed back to server A
> for
> encryption and tranmission to the client.
>
> This works fine for static files.
>
> .... BUT ....
>
> Mod_perl scripts seem to fail:
>
> https://turbo10.com:446/cgi-bin/splashpage1.cgi
>
> The log reports:
>
> [Mon Oct 14 21:33:25 2002] [error]
> proxy:http://turbo10.com:44300/cgi-bin/splashpage1.cgi not found or
> unable
> to stat
>
> However, when I access the proxy directly, the mod_perl script
> works fine (no access restrictions just yet):
>
> http://turbo10.com:44300/cgi-bin/splashpage1.cgi
>
> Any ideas? Is there some weird interaction between mod_perl +
> mod_proxy?
>
> Even better ... is there a way to do SSL compression in
> mod_perl
> with only one server?
>
> Any help would be much appreciated.
>
> NIgel
>
>
> MOD_GZIP WITH SSL MINI HOWTO
>
> Version 0.2 February 23, 2002
> Tim Behrendsen
> This document is released into the public domain.
>
> INTRODUCTION
>
> This document describes how to run mod_gzip over SSL connections using
> mod_ssl. The method described has been tested with Apache 1.3.22 under
> RedHat 7.2 (Kernel 2.4.13), mod_gzip 1.3.19.1a, mod_ssl 2.8.5 and
> OpenSSL
> 0.9.6b.
>
> THE PROBLEM
>
> One would expect to be able to just plug in mod_gzip into Apache in the
> normal way, and have it work with SSL. Unfortunately, due to technical
> issues with mod_ssl beyond the scope of this document (apparently
> mod_ssl
> greedily grabs the result before anyone else has a chance), the easy
> solution doesn't work.
>
> There are workarounds, however, that give the desired result.
>
> THE SOLUTION
>
> A workaround solution is to use mod_proxy. A front-end SSL-enabled
> Virtual
> Host receives the request, and then uses mod_proxy to pass the result to
> a
> back-end non-SSL virtual host that processes the request, compresses the
> content and passes it back. The front-end then happily forwards the data
> through the SSL connection.
>
> CONFIGURATION
>
> Install and test mod_gzip. Insallation information and sample
> configuration
> may be found on the home page of mod_gzip at
> http://www.remotecommunications.com/apache/mod_gzip. It's recommended to
> get
> mod_gzip completely working before adding SSL.
>
> After installing mod_gzip, enable mod_proxy in the configuration file by
> adding or uncommenting the following lines to the appropriate areas
> (near
> directives of the same form would be a good place). Note that the
> mod_gzip
> module needs to be the last one in the chain, so activate these before
> the
> mod_gzip module.
>
> LoadModule proxy_module modules/libproxy.so
>
> AddModule mod_proxy.c
>
> Some mod_gzip configurations apparently need the following line. Add it
> to
> your "item_include" sections:
>
> mod_gzip_item_include handler ^proxy-server$
>
> Add the following lines to your SSL VirtualHost:
>
> ProxyRequests On
> ProxyPass / http://localhost:44300/
> ProxyPassReverse / http://localhost:44300/
> mod_gzip_on No
>
> This directs mod_proxy to send all requests to a back-end virtual host
> on
> port 44300. Note that the "http" is required.
>
> Finally add a virtual host section similar to your primary SSL section,
> but
> without the SSL set-up. Note the security clause disabling access from
> anywhere but localhost (127.0.0.1), which prevents a non-SSL "backdoor"
> into
> your web server. This is optional, but recommended. It might also be a
> good
> idea to make sure your firewall blocks requests to 44300 (or whatever
> port
> you choose) just in case.
>
> Listen 44300
> <VirtualHost _default_:44300>
> <Directory />
> order deny,allow
> deny from all
> allow from 127.0.0.1
> </Directory>
> ...host information...
> </VirtualHost>
>
> Restart Apache, and that should be it!
>
> PROBLEMS
>
> Q: Error log gives:
> mod_gzip: EMPTY FILE [/tmp/_3630_118_19.wrk] in sendfile2
> mod_gzip: Make sure all named directories exist and have the correct
> permissions.
>
> A: There are a number of causes for this error, but in the context of
> SSL,
> this can be caused when mod_gzip is enabled for the SSL section. Make
> sure
> it's either disabled using "mod_gzip_on No" or by specifying the
> mod_gzip
> parameters only within the virtual host.
>
> Q: I'm getting redirected to the non-SSL page!
>
> A: Are you using mod_rewrite to fix trailing slashes or other mods? Try
> removing it in the back-end non-SSL virtual host. Keep the rewrites on
> the
> front-end.
>
> Q: When I press "refresh" on my browser, the page is getting corrupted!
>
> A: Unfortunately, IE6 (and perhaps earlier versions?) appears to have a
> bug
> with gzip over SSL where the first 2048 characters are not included in
> the
> HTML rendering of the page when refresh is pressed. It only seems to
> happen
> on longish pages, and not when the page is first loaded. In fact,
> sometimes
> it doesn't happen at all. The only current solution is to put a 2048
> character comment at the start of your longish pages of all spaces
> (which
> compresses pretty well, fortunately).
>
>
>
--
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.
