Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:279
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Reply-To: ilia@prohost.org
To: internals@lists.php.net
Date: Tue, 25 Mar 2003 16:11:12 -0500
User-Agent: KMail/1.5
Organization: Prohost.org
MIME-Version: 1.0
Content-Type: Multipart/Mixed;
  boundary="Boundary-00=_wXMg+c2cjhcaxGU"
Message-ID: <200303251611.12012.ilia@prohost.org>
Subject: Re: [PHP-DEV] Preliminary Apache 2 benchmarks
From: ilia@prohost.org ("Ilia A.")

--Boundary-00=_wXMg+c2cjhcaxGU
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

After further reviews I determined that 1000 request is too small and is often 
affected by external factors far too much and tends to fluctuate wildly. 
Therefor I've made a new set of tests based on 5 run of 10,000 request each  
for every SAPI. The tests were ran at a 10 second interval with a 20 second 
interval between different tests.
The source code of the tests is as follows:
bench.php
<?php
for ($i=0; $i<100;$i++) {
        echo $i;
}
?>

This test hopefuly allows to see the performance of many small writes

bench2.php
<?php
        $str = str_repeat('a', 4096);
        for ($i=0; $i<8; $i++) {
                echo $str;
        }
?>

A more realistic test designed to see how the same can handle a fewer number 
of larger writes one may expect to see when using output_buffering.

bench3.php
<?php
        echo str_repeat('a', 30000);
?>

A test designed to determine speed of hopefuly fast writes of large data 
chunks.


The tests were all based on identical configuration of PHP 4.3.2-cvs (debug 
version) made updated this morning. And they were executed from a local 
server to another server over a 100mbit lan with maximum capacity ~11meg/sec.

------                  AP1             AP2-filter              AP2-handler     
AP2-handler+patch
bench.php               232.73  139.50          87.70                   176.03
bench2.php      133.03  120.10          121.27          119.77
bench3.php      136.67  124.10          124.27          123.93


In an attempt to correct some remaining fluctuations, are particularly visible 
in Apache 2 tests, I've discounted the fastest & the slowest test and the 
number shown above represent the average speed of the 3 'middle' tests.

My interpretation of this is that writing large amounts of data in fewer steps 
seems to be the main performance difference between all filters. With the 
current AP2 handler being extremely slow. Writing large data is virtually 
identical across all Apache 2 sapis, so any difference maybe accounted by the 
margin of error. 
Apache 1 sapi is still faster and while the difference is not great only 10 
request/second it should be noted that Apache 1 module was 
lointernals@lists.php.netaded dynamically 
and another 10-20% can be added to it had the PHP module been compiled 
directly into apache.

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.

Unfortunately the actual benchmarks cannot be posted due to the message limit 
of 30k, if you want to see those, e-mail me and I'll will forward them to 
you.

Ilia
--Boundary-00=_wXMg+c2cjhcaxGU
Content-Type: text/plain;
  charset="us-ascii";
  name="ap2.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="ap2.txt"

Index: sapi_apache2.c
===================================================================
RCS file: /repository/php4/sapi/apache2handler/sapi_apache2.c,v
retrieving revision 1.1.2.5
diff -u -3 -p -r1.1.2.5 sapi_apache2.c
--- sapi_apache2.c	25 Mar 2003 01:34:39 -0000	1.1.2.5
+++ sapi_apache2.c	25 Mar 2003 21:40:51 -0000
@@ -84,6 +84,7 @@ php_apache_sapi_ub_write(const char *str
 						 r->connection->bucket_alloc);
 	APR_BRIGADE_INSERT_TAIL(brigade, bucket);
 
+#ifdef ilia_0
 	/* 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
@@ -91,7 +92,7 @@ php_apache_sapi_ub_write(const char *str
 	 */
 	bucket = apr_bucket_flush_create(r->connection->bucket_alloc);
 	APR_BRIGADE_INSERT_TAIL(brigade, bucket);
-	
+#endif
 	if (ap_pass_brigade(r->output_filters, brigade) != APR_SUCCESS) {
 		php_handle_aborted_connection();
 	}

--Boundary-00=_wXMg+c2cjhcaxGU--