# Preliminary Apache 2 benchmarks

- Thread: https://externals.io/message/279
- Original archive: https://news-web.php.net/php.internals/279
- Started by Ilia A. on 2003-03-25T21:11:12+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #279 — Ilia A. — 2003-03-25T21:11:12+00:00

URL: https://externals.io/message/279#279

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

---

## #281 — lists@holsman.net — 2003-03-25T21:43:41+00:00

URL: https://externals.io/message/279#281 · In reply to: #279

resend due to 30k issue.


> 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.

in the general (like 99.9%) of the case you don't need to flush.
I think disabling it will be a good thing.

the original version I committed actually waited until the entire page was parsed
before sending anything up the chain.

this is slightly different to what it currently does, and I'll try to see if I can see a difference 
in this approach (compared to sending the buckets up the filter chain)

if there is a difference, I'll add a new directive to buffer the response up.
> Ilia

---

## #282 — Ilia A. — 2003-03-25T21:55:15+00:00

URL: https://externals.io/message/279#282 · In reply to: #281

> resend due to 30k issue.
>
> > […]
>
> in the general (like 99.9%) of the case you don't need to flush.
> I think disabling it will be a good thing.

We do give the ability to the user to force a flush is they so desire, so I 
think disabling the automatic flushing of data would be a good idea 
especially since performance benefits are so significant.

> the original version I committed actually waited until the entire page was
> parsed before sending anything up the chain.
>
> this is slightly different to what it currently does, and I'll try to see
> if I can see a difference in this approach (compared to sending the buckets
> up the filter chain)
>
> if there is a difference, I'll add a new directive to buffer the response
> up.
>

Ok, let me know what you tests end up showing, I'd definately like to see some 
sort of a solution for this issue appear in the upcomming 4.3.2 release.

Ilia