Use the php.ini directive: implicit_flush. If it's set to on, then flush. If it's not then don't implicitly flush.
> -----Original Message----- > From: Ilia A. [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 25, 2003 4:55 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [PHP-DEV] Preliminary Apache 2 benchmarks > > > On March 25, 2003 04:43 pm, [EMAIL PROTECTED] wrote: > > resend due to 30k issue. > > > > > Attached is the patch (ap2.txt) that prevents AP2 handler > from constantly > > > flushing the data as soon as it is passed. As you can see in the > > > benchmarks this more the doubles the performance when many > writes occur. > > > I am hoping Ian can explain the need for this flush, since > without it the > > > code would be clearly faster. > > > > in the general (like 99.9%) of the case you don't need to flush. > > I think disabling it will be a good thing. > > We do give the ability to the user to force a flush is they so > desire, so I > think disabling the automatic flushing of data would be a good idea > especially since performance benefits are so significant. > > > the original version I committed actually waited until the > entire page was > > parsed before sending anything up the chain. > > > > this is slightly different to what it currently does, and I'll > try to see > > if I can see a difference in this approach (compared to sending > the buckets > > up the filter chain) > > > > if there is a difference, I'll add a new directive to buffer > the response > > up. > > > > Ok, let me know what you tests end up showing, I'd definately > like to see some > sort of a solution for this issue appear in the upcomming 4.3.2 release. > > Ilia > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
