Bill Stoddard <[EMAIL PROTECTED]> writes:
[...]
> At about how many headers is the performance benefits of this patch
> lost?
It's hard to give a brief answer to this question, but I'll
give it a try.
The patch leverages the checksum & table index code; it will
win whenever those optimizations are working well, and
it will lose when they are working poorly.
There are essentially two factors that go into this:
1) the quality of the key_checksum,
2) the spread between index_first and index_last.
The checksum is good whenever headers are distinguishable
by their first 4 letters, since it eliminates calls to
strcasecmp. The spread between index_first & index_last
measures the "clumpiness" of the distribution of the
headers' first letters.
Normally both of these factors are in the patch's favor.
Typically the key_checksum can distinguish most headers,
and the spread between index_first & index_last for
each letter is less than 16. I would expect the patch
to win in such cases.
For example, the headers range here from "Acommon" to
"Pcommon" and are duplicated once. Even though the
spread for each letter ("A" .. "P") is 16, which is
atypically large, the key_checksum can distinguish
headers and the patch wins:
% perl -wle '$X="A";$args.="-H ".$X++."common:foo=bar " for 1..16; \
exec qq{ab $args $args -n 50000 -c 50 http://127.0.0.1:8080/foo}'
=> UNPATCHED : 895 requests/second
APR PATCHED : 913 requests/second
But the pathological case is when all headers have at
least the first four letters in common. In such a situation,
the above optimizations are worthless, and the patch
underperforms the current code at about 8 headers
(because strcasecmp is grinding up the CPU).
--
Joe Schaefer
