httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: FW: Apache Optimization - Post-graduate Research
Date Thu, 27 Sep 2001 13:54:09 GMT

> dean gaudet wrote:
>
> >your numbers look about in the right ballpark for the top performance
> >you'll get from apache on that hardware.  the apache architecture has some
> >fundamental performance issues... consider using TUX instead (it's
> >included with redhat 7.1) or X15 (which is also linux, userland only and
> >performs as well as TUX).
> >
>
> This is related to an issue that I've been thinking about lately...
>
> I characterize Apache's performance as being limited by two very
> different classes of factors:
>
>   * Architectural factors -- e.g., a thread-per-connection server
>     generally will be slower than an event-loop server.
>
>   * Implementation factors -- e.g., using O(n)-time algorithms where
>     O(log(n)) is possible, or making extraneous system calls.
>
> In the past, implementation factors seem to have had a nontrivial
> effect on Apache's performance.  For 2.0, we've made some progress
> in fixing this through numerous optimizations to bottlenecks in the
> user-space code.  As we continue to fix the implementation inefficiencies,
> 2.0's throughput and CPU utilization will asymptotically approach the
> limits of its architecture on each platform.
>
> The interesting question is: once we've finished fixing the implementation
> factors (where "finish" means "reach a point of diminishing returns"),
> and architecture has a bigger impact on performance than implementation
> does, how will the performance compare to servers with different
> architectures?

> I expect that Apache 2.0 with the worker MPM will be
> slower than in-kernel servers and multiple-connection-per-thread
> user-space servers, but it's not clear how big the speed difference
> will be.

>From my experience, a properly implemented kernel engine will be from 1.5 to 2x faster
than the fastest user space implementations (Zeus, IIS for example). An event driven
server will be somewhat faster than a thread-per-connection server.  The real advantage of
an event driven server is that it scales well to large numbers of concurrent clients.

FWIW, the worker MPM is a step in the right direction for making Apache an event driven
server. We just need to mangle the core HTTP parsing engine to make it stateful and impose
some programming disiplines on an async Apache API. Good 3.0 stuff :-)

Bill


Mime
View raw message