httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: Apache 2.0 Numbers
Date Mon, 24 Jun 2002 16:07:34 GMT
On Mon, 2002-06-24 at 02:16, Andi Gutmans wrote:

> >   * PHP's nonbuffered output mode produces very small socket writes
> >     with Apache 2.0.  With 1.3, the httpd's own output buffering
> >     alleviated the problem.  In 2.0, where the PHP module splits
> >     long blocks of static text into 400-byte segments and inserts
> >     a flush bucket after every bucket of data that it sends to the
> >     next filter, the result is a stream of rather small packets.
> 
> You should test this with PHP's internal output buffering enabled. You can
> set it there to something like 4096.

That definitely will improve the numbers, but I'd rather not spend the
next few years saying "turn on buffering in mod_php" every time another
user posts a benchmark claiming that "Apache 2.0 sucks because it runs
my PHP scripts ten times slower than 1.3 did." :-)

I have two proposals for this:

* Saying "turn on buffering" is, IMHO, a reasonable solution if you
  can make buffering the default in PHP under httpd-2.0.  Otherwise,
  you'll surprise a lot of users who have been running with the default
  non-buffered output using 1.3 and find that all their applications
  are far slower with 2.0.

* A better solution, though, would be to have the PHP filter generate
  flush buckets (in nonbuffered mode) only when it reaches a "<%" or
  "%>".  I.e., if the input file has 20KB of static text before the
  first embedded script, send that entire 20KB in a bucket, and don't
  try to split it into 400-byte segments.  If mod_php is in nonbuffered
  mode, send an apr_bucket_flush right after it.  (There's a precedent
  for this approach: one of the ways in  which we managed to get good
  performance from mod_include in 2.0 was to stop trying to split large
  static blocks into small chunks.  We were originally concerned about
  the amount of time it would take for the mod_include lexer to run
  through large blocks of static content, but it hasn't been a problem
  in practice.)

>From a mod_php perspective, would either of those be a viable solution?

--Brian



Mime
View raw message