Hi,
I am wondering what might be the easiest way to resemble the semantics
of
lighttpd’s compress.cache-dir:
| server.modules = ( “mod_compress” )
| compress.filetype = (“text/javascript”, “text/css”)
| server.document-root = “/web”
| $HTTP[“url”] =~ “^/static/” {
| compress.cache-dir = “/web_cache”
| }
What it does is to automatically generate gzipped representations of
files below /web/static/ (according to their last-modified time) in the
directory /web_cache. I find this very handy and it greatly reduces the
load for serving compressed files which change rarely.
On nginx, however, I cannot see how I could resemble this semantic with
only “gzip on” or “gzip_static on”–is that correct?
Best,
Sven
On Wed, Sep 24, 2008 at 2:22 PM, Sven C. Koehler [email protected]
wrote:
What it does is to automatically generate gzipped representations of
files below /web/static/ (according to their last-modified time) in the
directory /web_cache. I find this very handy and it greatly reduces the
load for serving compressed files which change rarely.
On nginx, however, I cannot see how I could resemble this semantic with
only “gzip on” or “gzip_static on”–is that correct?
gzip_static on basically just checks for file.txt.gz if the request is
for “file.txt” - it is useful for pre-gzipping your content. also it’s
best to keep the modified times the same so that things aren’t
confused 
you should eb fine with just gzip on; - nginx’s gzipping is
-extremely- fast. it doesn’t cache items by default, gzip_static is
not a workaround for that, it’s actually a different -type- of
feature, and ultimately does give you a bit more control over how your
content is compressed ahead of time.
i believe most webservers have a cache dir for saving the gzipped
content so it doesn’t have to re-gzip the stuff; at first i thought
nginx was crazy. but after using it i’ve realized that it still
outperforms everything else even with real-time gzipping…
On Wed, Sep 24, 2008 at 02:46:17PM -0700, mike wrote:
you should eb fine with just gzip on; - nginx’s gzipping is
-extremely- fast. it doesn’t cache items by default, gzip_static is
not a workaround for that, it’s actually a different -type- of
feature, and ultimately does give you a bit more control over how your
content is compressed ahead of time.
Thanks for that information! Did you see differences in performance
when
using different compression levels for ningx’s gzip?
-S.
On Wed, Sep 24, 2008 at 3:28 PM, Sven C. Koehler [email protected]
wrote:
Thanks for that information! Did you see differences in performance when
using different compression levels for ningx’s gzip?
I’ve never ran any benchmarks, sorry. I have no tangible data for that
