Re: Improved transparent compressor

Zeev Suraski wrote... > I haven't looked into this patch, but can't this be done using the chunked > output buffering support? A 4KB buffer should be much more efficient than > compressing each and every separate piece of output... The chunked output > buffering support made it into 4.0.4, although it's untested, and > ob_gzhandler() wasn't yet updated to take advantage of it. I was unaware of chunked output. I have now read the code. I like the idea for very high data throughput servers. I'm not sure it will make much difference in a compression situation. The CPU consumed doing compression is so much larger than the cost of the extra function calls that the compression time will strongly dominate. I believe chunking will work out-of-the-box with my compression patch, if there is someway to do the chunking with the standard output handler. I didn't see one but can imagine how to add one. (Allow a 0 for the handler argument in the two argument form of ob_start(), use that to indicate the standard handler). If you like I will add this and collect some performance data. I believe ob_gzhandler will need a major rework to use chunking. The trick is that ob_gzhandler puts the header and trailer on the content all in one call. If it is going to be called many times for the same request then it needs to know which is the first (easy) and which is the last (needs new mechanisms elsewhere in php). Proper flushing also requires other hooks in both the compression and I think the chunking code. After ob_gzhandler has done this it will be turned into the same thing as my version of the compression patch. :-) I've got an NT capable version of the patch finished (I didn't know about when to use OLS_FETCH()) it also now handles zero length writes (deflate() returns an error on those which must be ignored or avoided). It is in formal testing as part of a delivered system this week. I'll resubmit a refined version after it passes. -- Jim Studt, President The Federated Software Group, Inc.