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
[EMAIL PROTECTED] 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.
IliaIndex: 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();
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
