httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Gutmans <>
Subject Re: Apache 2.0 Numbers
Date Mon, 24 Jun 2002 09:16:35 GMT
On Sun, 23 Jun 2002, Brian Pane wrote:

> On Sun, 2002-06-23 at 18:58, Rasmus Lerdorf wrote:
> > Someone asked me for numbers when I mentioned the other day that Apache
> > 2-prefork was really not a viable drop-in replacement for Apache 1.3 when
> > it comes to running a PHP-enabled server.
> > 
> > Apache 1.3 is still significantly faster than Apache2-prefork for both
> > static and dynamic content.
> Most of the static benchmarks that I've seen posted to dev@httpd
> (including my own tests on Solaris and Linux) indicate otherwise.
> And for dynamic content, it's tough to make any generalization that
> one httpd release is faster than another, because the performance
> depends heavily on one's choice of content generation engine.
> > Now, part of the blame goes to PHP here for
> > the dynamic case. We are compiling PHP in threadsafe mode when building
> > the PHP DSO for Apache2-prefork which is not necessary.
> You'll definitely see slow performance with PHP and httpd-2.0.
> I know of two major factors that contribute to this:
>   * mod_php is using malloc and free quite a bit.

This shouldn't make a difference with the pre-fork MPM. It should be the
same speed as with 1.3. In any case, I'm in the middle of writing a
per-thread memory manager for the threaded MPM which doesn't use any
locks (except for allocating huge chunks) and allows frees.
The APR memory pools don't do this. It should improve performance under
OS's which don't have native per-thread pools (Win32 has them). But again,
it has nothing to do with Apache 1.3 vs. Apache 2.

>   * PHP's nonbuffered output mode produces very small socket writes
>     with Apache 2.0.  With 1.3, the httpd's own output buffering
>     alleviated the problem.  In 2.0, where the PHP module splits
>     long blocks of static text into 400-byte segments and inserts
>     a flush bucket after every bucket of data that it sends to the
>     next filter, the result is a stream of rather small packets.

You should test this with PHP's internal output buffering enabled. You can
set it there to something like 4096.


View raw message