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.
I would think that this would be a case wherer the php developer is stating that the server's core_output_filter and the OS's TCP driver CAN'T make a better decision. If I were a php developer, I would only use the unbuffered write call if I was about to perform an operation that was likely to take a long time. That way, I could at least start to get content to the user ASAP (most likely a message explaining the delay), then I could do the long-lasting operation without worry about my user clicking reload. Ryan _______________________________________________________________________________ Ryan Bloom [EMAIL PROTECTED] 550 Jean St Oakland CA 94610 -------------------------------------------------------------------------------
