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
