[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]
