> In my case, it appears Apache selects the chunked encoding automagically > when the size of the page goes over a certain size. Apache doesn't seem > to set the smaller pages to the chunked encoding (even though they are gzipped). No, this was wrong. Mod_file_cache was tricking me (again). Apache appears to set the Transfer-Encoding to chunked when the page is actively being gzipped and the final gzip file is bigger than DeflateBufferSize. But if the page was gzipped and stored on disk by mod_file_cache (like we do) it means Apache is merely spooling the file off the disk (it doesn't put it though gzip a second time) and chunked encoding will *not* be used. Now I'm going to speculate that a chunked gzip web page is going to be slower than the unchunked equivalent because the browser have to spend "some amount" of time putting the chunked version back together. But I'm wrong again. We just tested this and the timing of Firefox 4's load event didn't increase with the number of chunks. Even setting DeflateBufferSize down to 500 bytes on a 40K page didn't produce consistent differences. The one consistent metric was that with chunking on (DeflateBufferSize smaller than total compressed page size), Apache was able to get the first byte to the web browser about 75ms faster but again, the faster response time didn't translate into a consistently faster rendering of the page by the browser. This testing needs further study before it's taken as gospel. We only ran about 4 tests per DeflateBufferSize. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|