httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Gutmans <>
Subject Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter
Date Sat, 08 Jun 2002 11:59:29 GMT
On Fri, 7 Jun 2002, Ryan Bloom wrote:

> On Fri, 7 Jun 2002, Brian Pane wrote:
> > On Fri, 2002-06-07 at 01:14, Sascha Schumann wrote:
> > > > The function php_apache_sapi_ub_write() is inserting a flush bucket
> > > > after each bucket of data that it adds to the output brigade.
> > > 
> > >     The 'ub' stands for unbuffered.. you can avoid that by
> > >     enabling output buffering in php.ini.
> > 
> > IMHO, that's a design flaw.  Regardless of whether PHP is doing
> > buffering, it shouldn't break up blocks of static content into
> > small pieces--especially not as small as 400 bytes.  While it's
> > certainly valid for PHP to insert a flush bucket right before a
> > block of embedded code (in case that code takes a long time to
> > run), breaking static text into 400-byte chunks will usually mean
> > that it takes *longer* for the content to reach the client, which
> > probably defeats PHP's motivation for doing the nonbuffered output.
> > There's code downstream, in the httpd's core_output_filter and
> > the OS's TCP driver, that can make much better decisions about
> > when to buffer and when not to buffer.

We did quite a lot of tests on this issue a couple of years ago and found
that not scanning all of the embedded HTML in one big piece but breaking
it down to chunks around 400bytes yields better performance.

I can say that in general, best performance with PHP is achieved when
using full output buffering. ASP seems to do the same and while we were at
MS Labs doing benchmarks of PHP vs. ASP this was one of the settings we
found made PHP compete well with ASP.

Another change we made, as I mentioned in a previous Email, was using
non-mutexing per-thread memory pools (HeapCreate(HEAP_NO_SERIALIZE, ...)).
To get best performance with Apache 2 we would really need such a memory


View raw message