Gzip is a good way to make your web site faster. It may decrease the size of downlodable documents by half. This seriously speeds up the loading of the site because network delays affects the performance (and user satisfaction) most.
But there is a drawback of the gzip compression that many people do not realize.
In the early Apache 1.x days mod_gzip had a very nice feature: file cache for the compressed content. mod_deflate in Apache 2 does not have any caching for the compressed content. It means that downloading 500KB of ExtJS with compression means compression this file each time. If there is no client cache or mod_proxy, this becomes a major problem. It seriously increases the load on the server. Also it slows down the response time because the file has to be compressed each time. It is a serious issue to consider for large web sites. Even client caching is not a solution.
The solution that I use for such cases is a pre–compression of such files. Then I use a mod_rewrite checks and rules to rewrite requests to these files to their compressed versions. It speeds up the loading (by 1-2 seconds in case of ExtJS).
Comments
Dmitry - how would such a rewrite section look like? And you you compress eg the ExtJS file yourself before?
Regards,
Jochen
This resolves the gzip problem and obviously has further advantages.
Marcus, proxy means extra CPU too and I'll have to create rules to skip caching pages. I expect that precompressed files + mod_rewrite will be faste, more robust and easier to setup.
As to our experience a gzipping and caching proxy will eg. offload +70% from the real webserver, for the cost of max 15% of CPU/MEM.
However the benefit and metrics, as always, depend on the nature (templating, caching...) of the instance.
Add a comment
All fields in this form are required!