On Fri, Oct 5, 2012 at 1:51 PM, Lieven Govaerts <l...@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
