On 14/05/2013 2:44 a.m., babajaga wrote:
First of all, question was more "how to do", and not "why to do".
Anyway, there can be two reasons:
- You might reduce stress on busy disks because of smaller transferes. And
more buffering before transfer.
- One step into bandwidth saving towards the client.
But the object o disk is NOT the same as the object delivered to the client.
It contains a lot of meta data and headers information which both needs
to be accessed very fast for cache rebuild, and filtered away on the
client-delievered stream. So compressing the file on disk cache just
means compressing it when writing to disk, decompressing when reading
from disk re-compressing when delivering to client. Possibly doing all
three compress/decompress/recompress in parallel if a REFRESH happens
(as they frequently do).
How much page loading delays exactly are clients willing to face just so
you can save buying a second disk?
Although, in general you are correct. But in case of caching a lot of
textual stuff, it could be a possibility, because you can get a high
compression rate, effectively doubling your storage, even more, may be.
Then it *needs* to be compressed by the origin server delivering it,
such that the ETag identifiers etc are correctly assigned to the
compresses forms and revalidation can operate on them cleanly.
PS. there is an eCAP adaptor out the which does gzipping of client
responses to save traffic. IIRC there were complaints about the drop in
speed it added to the proxy, and all it was doing was passing responses
through a fast gzip streamer *once* during delivery, none of the
multiple streams being requested here. There have also been various
experiments with replacing client Accept headers to force the response
compression on the origin - they work better from the proxy performance
viewpoint but frequently break API services and SaaS systems using HTTP.
Amos
