Re: Preliminary Apache 2 benchmarks

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

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(); }