Benchmarks for Apache 1.3.24 versus Apache 2.0.35

[Andrew Ho <an...@tellme.com>]

Hello,

I ran some benchmarks on Apache 1.3.24 versus Apache 2.0.35 that you may
find interesting. Particularly, I found the worker MPM suffers performance
issues on our dual-processor Solaris x86 systems. pbinding Apache to a
single processor improves performance at higher concurrency levels, but in
a somewhat unpredictable way.

The benchmarks are naive (so far using only ab to select a small 1k text
file), but probably generally representative.

The benchmarks can be found here:

    http://www.zeuscat.com/andrew/work/aprbench/

If benchmarks shouldn't be posted to this list, I apologize in advance;
please reply to me privately and I won't do it again when I rerun some
more refined tests.

Humbly,

Andrew

----------------------------------------------------------------------
Andrew Ho               http://www.tellme.com/       andrew@tellme.com
Engineer                   info@tellme.com          Voice 650-930-9062
Tellme Networks, Inc.       1-800-555-TELL            Fax 650-930-9101
----------------------------------------------------------------------

Re: Benchmarks for Apache 1.3.24 versus Apache 2.0.35

[Brian Pane <br...@cnet.com>]

Andrew Ho wrote:

>Hello,
>
>I ran some benchmarks on Apache 1.3.24 versus Apache 2.0.35 that you may
>find interesting. Particularly, I found the worker MPM suffers performance
>issues on our dual-processor Solaris x86 systems. pbinding Apache to a
>single processor improves performance at higher concurrency levels, but in
>a somewhat unpredictable way.
>
>The benchmarks are naive (so far using only ab to select a small 1k text
>file), but probably generally representative.
>
>The benchmarks can be found here:
>
>    http://www.zeuscat.com/andrew/work/aprbench/
>

Thanks!  This is great data.  Your results match what I've seen in other
benchmarking: the prefork MPM generally outperforms worker.  This makes
sense, given that the worker MPM does a little more work for each connection
than prefork: putting the connection in a queue, awakening a worker thread,
and all the associated mutex operations.

If you're interested in testing some experimental code, try the 
leader/follower
MPM (from a current CVS snapshot, re-run buildconf and then
"configure --with-mpm=leader").  It's a mutation of the worker design that
tries to reduce the context switching and mutex locking overhead.  (One 
known
problem, though: leader/follower is faster than worker when you configure it
to listen on a single port, but slower when you configure it to listen 
on two
or more ports.  I haven't yet figured out the reason why...)

With regard to Apache 2.x performance on Solaris in general, one outstanding
problem is that the implementation of fcntl (used to put newly accepted 
connections
in nonblocking mode) is a bit slow on Solaris.  On the other hand, 
Solaris 8 lets
the accepted socket inherit the nonblocking flag from the listener 
socket.  We
may be able to speed things up by putting the listening socket in 
nonblocking
mode and skipping the fcntl on each connection.  (But this will prevent 
the use
of single-listener-unserialized-accept.)

--Brian