gzip - unexplained side effects

[Igor Sysoev]

On Tue, Nov 08, 2011 at 09:14:04PM -0500, dbanks wrote:
> Hi,
> 
> I'm running nginx 1.0.0 in front of a FCGI backend.  We've been running
> in production for about 4 months, and have really been impressed with
> the performance and stability of nginx.
> 
> We run a medium-volume appliction: 1000 to 4000 requests/sec spread over
> 2 instances by an upstream round robin load balancer.  We use
> keepalives, but keep them rather short given the request volume to keep
> the number of open connections manageable.  
> 
> Recently, I was working to improve our gzip settings.  The largest
> change was that I added an explicit gzip buffer line (find my config
> below - the three lines that are commented out seem to be correlated
> with this issue)
> 
> After the change, the volume of outbound traffic decreased measurably,
> as if gzip was not originally doing much due to inadequate buffer space.
>  Great news!, or so I thought.  What also changed was that the number of
> active connections fell by about 75% - the gzip change was somehow
> causing keepalives to be closed prematurely.  Also, our volume of
> incoming requests decreased a bit: as if some requests were being
> aborted (though accepts == handled).   The request volume makes
> debugging this particular issue somewhat troublesome, since I have yet
> to replicate it in a quiet instance.
> 
> The guts of my configuration appear below.  This is such an unexpected
> issue that I'm not doing a great job of setting up my question well. 
> What I think I'd like to know is how could a change to the gzip buffers
> (or the other two commented changes) impact keepalives or overall
> connection negotiation?  Also, any suggestions as to how to go about
> debugging it?
> 
>     sendfile        off;  
>     tcp_nodelay on;  
>     ignore_invalid_headers  on;  
>     if_modified_since off;
> 
>     gzip on;
>     gzip_comp_level 9;
>     gzip_types text/javascript text/plain application/x-javascript;
>     gzip_disable "MSIE [1-6]\.(?!.*SV1)"  
>     #gzip_buffers 512 4k;
>     #gzip_min_length  1100;  #if it fits in one packet, no worries
>     #gzip_http_version 1.1;
> 
>     keepalive_timeout  6;  
>     keepalive_requests 4;  

If you comment gzip_buffers, you see the previous site state ?
What is typical uncompressed and compressed response size ?
The default gzip_buffers are "32 4k", so they can keep up to 128K.

And as it was already suggested it's better to use default
gzip_comp_level 1.


-- 
Igor Sysoev