Nginx Fastcgi_cache performance - Disk cached VS tmpfs cached VS serving static file

Maxim Dounin mdounin at mdounin.ru
Fri Oct 4 17:43:53 UTC 2013


Hello!

On Fri, Oct 04, 2013 at 12:52:28PM -0400, ddutra wrote:

> Maxim,
> Thank you again.
> 
> About my tests, FYI I had httpauth turned off for my tests.
> 
> I think you nailed the problem.
> 
> This is some new information for me.
> 
> So for production I have a standard website which is php being cached by
> fastcgi cache. All static assets are served by nginx, so gzip_static will do
> the trick if I pre-compress them and it will save a bunch of cpu.
> What about the cached .php page? Is there any way of saving the gziped
> version to cache?

Yes, but it's not something trivial to configure.  Best aproach 
would likely be to unconditionally return gzipped version to 
cache, and use gunzip to uncompress it if needed, see 
http://nginx.org/r/gunzip.

> Another question - most static assets are being worked in some way by
> ngx_pagespeed and the optimized assets are cached. That means .js, .css and
> images too. How does gzip works in this case? nginx gzips it everytime it
> gets hit? ngx_pagespeed caches gzipped content? I am confused.

I haven't looked at what pagespeed folks did in their module, but 
likely they don't cache anything gzip-related and the response is 
gzipped every time (much like with normal files).  It might also 
conflict with gzip_static, as pagespeed will likely won't be able 
to dig into gzipped response.

> Maybe it would be better to drop ngx_pagespeed, bulk optimize every image on
> source, minify all .js and .css, and let it all run on nginx without
> ngx_pagespeed cache. Can you share you experience on that?

In my experience, any dynamic processing should be avoided to 
maximize performance.  Static files should be optimized (minified, 
pre-gzipped) somewhere during deployment process, this allows to 
achieve smallest resource sizes while maintaining best 
performance.

> And one last question, is there any way to output $gzip_ratio on the
> response headers in order to do a easy debbuging?

No, as $gzip_ratio isn't yet known while sending response headers.  
Use logs instead.  Or, if you just want to see how files are 
compressed with different compression levels, just use gzip(1) for 
tests.

-- 
Maxim Dounin
http://nginx.org/en/donation.html



More information about the nginx mailing list