Posted by aharown07 on February 20, 2011 at 3:18am
Just starting running my sites on an nginx server I set up w/info from vpsBible.com
I'm not sure if nginx normally compresses/gzips or how to tell if I have that enabled. The Drupal perf. page says not to use page compression if the web server does, so... anyone know if nginx + Drupal page compression is a bad idea?
...or how to tell if my nginx is compressing or not?
Comments
If nginx is using
If nginx is using compression, your nginx.conf should have
gzip_static on;Check http://wiki.nginx.org/HttpGzipStaticModule for more settings.
nginx compression = native to the web server, including images, css, js files
Drupal compression = Drupal generated pages only, using php (in general needing more resources)
I'd recommend turning on nginx, turning off Drupal compression, but keeping aggregation of css and js (and caching if appropriate).
Not sure...
Thanks. Well, I don't have gzip_static in there, but I have "gzip on;" Looks like it's config'd to be compressing selectively.
Here's the code...
http {include mime.types;
default_type application/octet-stream;
sendfile on;
tcp_nopush on;
tcp_nodelay off;
keepalive_timeout 5;
gzip on;
gzip_comp_level 2;
gzip_proxied any;
gzip_types text/plain text/css application/x-javascript text/xml applic
include /usr/local/nginx/sites-enabled/*;
Right now I've got Drupal compression off but css & js aggregation. Seems to be working OK.
Edit: did a bit more reading. Looks like there's a HttpGZipStaticModule but also a HttpGzipModule. I've got the second one. Don't know if I've got the first one or not. Is one better than the other for Drupal?
In addition to what perusio
In addition to what perusio said, having both modules installed results in the server not having to do the extra work of compression every time a file is requested.
My understanding is that the file is compressed by the HttpGzipModule and then delivered by the HttpGZipStaticModule, which acts like a localized proxy cache(?) for delivering compressed files. So these two modules have some kind of understanding with Nginx where the files being delivered, will always be the latest version.
mod_gzip and mod_cache would probably be the equivalent from the Apache world.
Not really
The
HttpGZipStaticModulestatic module addresses only already compressed files. There's no interaction, AFAIK, with theHttpGzipModule.Caching has nothing to do with it. There's a 3rd party module
ngx_http_filter_cachethat runs as a filter after gzip and SSI. So the cached response will already be compressed.Thanks Perusio. My mind has
Thanks Perusio. My mind has not fully grasped how this works yet. For someone bootstrapping a business and having to play the temporary role of sysadmin, what would be the generally advised way to set-up specifically these modules for a Drupal multi-site stack serving mostly anonymous users? The object being simply to use minimal resources without degrading the end user experience in terms of responsiveness.
Would we have
NginxHttpGzipModuleandHttpGzipStaticModuleenabled, and then thengx_http_filter_cachemodule to ensure that gzipped content has some type of general cache logic/functionality for delivering latest content?For what reasons would we want to cache SSI requests?
From the filter_cache description...
filter_cache is very similar to the otehr caches in nginx. It uses the same underlying core functionality. However, it runs as a filter as late in the HTTP processing as possible. This allows it to cache things such as the results of SSI and gzip. It does not work on subrequests. filter_cache returns 599 on a cache miss. It returns 598 when the cache will be bypassed. Note: when the cache is bypassed, it will not attempt to cache it by default. This behavior is different from some other nginx caches.
Let's see
If you have no gzipped content on-disk then skip the
gzip_static on;Or set it to
offin more speed critical locations. Thus you save astat()call.I've never used the ngx_http_filter_cache. Perhaps you can try it and report back.
Yes, AFAIK is the only module that caches already gzipped pages, thus functioning, after the first call, as a gzip static file on-disk.
The gzip static
module ships already compressed files from the filesystem through the pipeline. It does a
stat()call and checks to see if the files exists (with agzextension) if it does it serves that file. If not then if there's agzip on;in the config it compresses the file on the fly and serves it if the file is of one of the specified types ingzip_types.