> [EMAIL PROTECTED] writes: > >> Stephen Pierzchala wrote: >> >> All: >> >> A question for discussion: should a lower bound be set in mod_deflate? >> >> I just ran a test using the Linux Documentation Project files and found >> that some of the files in the test group were quite small, less that 100 >> bytes. When mod_deflate tackled these files, I saw a file sized increase >> of between 12 and 15 bytes. >> >> Doesn't sound like a lot, until maybe you start to add up all of those >> HTML error pages we all send. >> >> I open the floor to debate. :-) > > > while this may be easy for the cases where the filter gets passed a > content-length header,
No brainer ( if it's accurate when the filter fires up ). > it may be harder for the ones where it doesn't > know the size of the page before it starts compressing.. Any filter is supposed to be able to buffer data. Harder, yes, but not impossible. The whole filtering scheme is SUPPOSED to be able to handle this, no problems. Not sure if anything has actually exercised this yet, though. Might be time to see if it really works. The 'cheap trick' compromise would be to realize that by the time the first brigade shows up there will probably be only one of 2 scenarios... 1. The response is less than the size of the fileread and/or CGI transfer buffer size ( 4k? ) and nothing else is coming ( There is already an EOS in the first brigade. This can be treated the same as having 'content-length' because you know for sure how long the full response is before you have to decide whether to fire up the compression. 2. If there's no EOS in the brigade yet you have to assume more is coming so now it's nut-crackin' time. If the 'minimum file size' is less than the amount of data already in the first brigade showing up then it's also a no brainer... just pass it on without compressing. If the minimum file size is larger than what's in the first brigade... then it's time to start buffering ( if the code allows it ). I would say that just allowing a 'minimum file size' in the 2-3k byterange and only doing the check on the first brigade would handle most situations where anyone is worried about whether something is worth compression. Anything over about 900 bytes is almost ALWAYS going to show some size reduction. Problem solved. If someone wants to start setting a minimum file size of 100,000 bytes then I would suggest the 'requirement' on their end be that all responses MUST have 'Content-Length:' from the origin ( if it's not a file read ) until mod_deflate can actually 'store and forward' any size response. > I'm cool with putting in a directive, but not sure how to write the doc's up > to say that this is a 'guidance' only and that it might be ignored. See above. Limit it to the normal (Apache) I/O buffer read size(s) and suggest that anything above that can/should have 'Content-Length' or it's not eligible for the 'minimum size' check. > we should also put in a directive to only compress when system load is > below a certain level. (but we would need a apr_get_system_load() > function first .. any volunteers? ) If you go down this route watch out for what's called 'back-flash'. You can easily get into a catch-22 at the 'threshhold' rate where you are ping-ponging over/under the threshhold because currently executing ZLIB compressions will always be included in the 'system load' stat you are computing. In other words... if you don't want to compress because you think the machine is too busy then it might only be too busy because it's already compressing. The minute you turn off compression you drop under-threshhold and now you are 'thrashing' and 'ping-ponging' over/under the threshhold. You might want to always compare system load against transaction/compression task load to see if something other than normal compression activity is eating the CPU. Low transaction count + high CPU load = Something other than compression is eating the CPU and stopping compressions won't really make much difference. High transaction count + high CPU load + high number of compressions in progress = Might be best to back off on the compressions for a moment. [EMAIL PROTECTED]
