httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sascha Schumann <>
Subject Re: PHP profiling results under 2.0.37 Re: Performance of Apache 2.0 Filter
Date Fri, 07 Jun 2002 16:49:48 GMT
> 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

    That sounds like the input size of the lexer which is a part
    which I'm not particularly proud of.

> 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 doubt that core_output_filter knows the script author's
    intentions very well.  Anyway, Aaron and Cliff posted a patch
    which was committed by Sebastian in mid-April which
    introduced this behaviour.

    /* Add a Flush bucket to the end of this brigade, so that
     * the transient buckets above are more likely to make it out
     * the end of the filter instead of having to be copied into
     * someone's setaside. */
    b = apr_bucket_flush_create(ba);

    The need for this should be reassessed.  Aaron/Cliff, can you
    please have a look at this?

    Please keep in mind that script authors can always use
    flush() to insert the flush-bucket.

    - Sascha

View raw message