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 pool. Andi
