apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe+gm...@sunstarsys.com>
Subject Re: call for vote Re: [PATCH] Re: Frankentables
Date Wed, 21 May 2003 15:40:34 GMT
Bill Stoddard <bill@wstoddard.com> 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


Mime
View raw message