Gzip vs. sendfile

Hi,

From https://www.nginx.com/blog/tuning-nginx/:

Note, however, that because the data never touches user space it’s not subject
to the filters in the regular NGINX processing chain. As a result, filters that
change content, for example the gzip filter, have no effect.

Which never occurred to me, but sounds reasonable. What is more
surprising is that I found virtually no discussion on this, and I
wasn’t able to reproduce it.

Using the following configuration:

types {
    text/plain txt;
}

gzip on;
gzip_comp_level 5;
gzip_types text/plain;

sendfile on;

the files are still served gzipped. The author of

says:

There is a tradeoff between using compression (saving your bandwidth) and using
the sendfile feature (saving your CPU cycles). If the connector supports the
sendfile feature, e.g. the NIO connector, using sendfile will take precedence over
compression. The symptoms will be that static files greater that 48 Kb will be
sent uncompressed.

However, increasing the file size to more than 200 KB still has no
effect on the encoding.

Is it actually the other way around and filters disable sendfile?

Ádám

Hello!

On Mon, Aug 24, 2015 at 11:50:10PM +0200, Joó Ádám wrote:

From https://www.nginx.com/blog/tuning-nginx/:

Note, however, that because the data never touches user space
it’s not subject to the filters in the regular NGINX
processing chain. As a result, filters that change content,
for example the gzip filter, have no effect.

Which never occurred to me, but sounds reasonable. What is more
surprising is that I found virtually no discussion on this, and
I wasn’t able to reproduce it.

The statement quoted is incorrect. Instead, if any filter is going
to change content, sendfile won’t be used. I’ll ping Rick to fix
this.

[…]

Is it actually the other way around and filters disable sendfile?

Yes.


Maxim D.
http://nginx.org/