On Fri, Oct 5, 2012 at 1:51 PM, Lieven Govaerts <lgo_at_apache.org> wrote:
> Hi,
>
[...]
>
> I have tested 4 different scenario's:
> 1. As-is setup, OpenSSL compression enabled + gzip encoding enabled. (double
> compression)
> 2. OpenSSL compression disabled + gzip encoding enabled. (compression
> handled by the application)
> 3. OpenSSL compression disabled + gzip encoding disabled. (no compression at
> all)
> 4. OpenSSL compression enabled + gzip encoding disabled (compression handled
> by OpenSSL)
>
> I found this particular scenario too small to see a measurable difference in
> memory or cpu usage, although this is interesting to test further.
>
> Difference in total times are more interesting:
> | bytes read | bytes written | total time
> 1: | 17.50MB | 233-284KB | 59s
> 2: | 18.67MB | 2.13-2.43MB | 1m9s-1m18s
> 3: | 50.35MB | 2.34MB | 103s-108s
> 4: | 15.27MB | 235-260KB | 50s-56s
>
[...]
> Given the above I propose the following:
> - Add an option in serf to disable OpenSSL compression
> - Add a function in serf to check if compression is enabled in OpenSSL.
> - In Subversion, don't ask for gzip encoding when working over https with
> compression.
> - In Subversion, if the config option "http-compression" is set to "no",
> disable both OpenSSL compression and gzip encoding.
>
> Which makes scenario 4 the default, and the user can select for scenario 3
> with the "http-compression" option.
>
> Patch to disable OpenSSL compression in serf is attached.
>
> Suggestions? Objections?
>
It seems I found easy fix for this issue. Just add Apache directive:
SetEnvIf SSL_COMPRESS_METHOD "DEFLATE" no-gzip
This line should disable mod_deflate if OpenSSL compression is used
for current connection. I'm going to test it tomorrow.
--
Ivan Zhakov
Received on 2012-10-17 21:45:23 CEST