Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:272
Return-Path: <ilia@prohost.org>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 81123 invoked from network); 25 Mar 2003 15:51:43 -0000
Received: from unknown (HELO asuka.prohost.org) (24.101.65.70)
  by pb1.pair.com with SMTP; 25 Mar 2003 15:51:43 -0000
Received: (qmail 11438 invoked from network); 25 Mar 2003 10:52:10 -0000
Received: from rei.nerv (HELO dummy.com) (rei@192.168.1.1)
  by asuka.nerv with SMTP; 25 Mar 2003 10:52:10 -0000
Reply-To: ilia@prohost.org
To: internals@lists.php.net,
 Ian Holsman <ianh@php.net>
Date: Tue, 25 Mar 2003 10:52:28 -0500
User-Agent: KMail/1.5
Organization: Prohost.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200303251052.28910.ilia@prohost.org>
Subject: Preliminary Apache 2 benchmarks
From: ilia@prohost.org ("Ilia A.")

Based on bug #22815, which talks about unsatisfactory performance of the 
apache 2 sapi, I've decided to conduct several benchmarks to determine the 
depth of the problem.

Based on my tests (ran using 4.3.2-cvs on 1Ghz celeron) it appears that the 
apache2handler is indeed slower.

The test script used was
<?php
for ($i=0; $i<100;$i++) {
        echo $i;
}
?>

This script resulted in a 270 byte header being generated in addition to 190 
bytes of actual content.

Apache 2 filter (the original apache 2 sapi) was able to handle 143 
requests/second, while Apache2handler (newer & more stable sapi) could handle 
only 133 requests/second. This represents aproximately 7% performance loss 
for rather small request.

My next test was an attempt to determine the performance difference for larger 
requests that one may encounter in real life situations.

Test script #2
<?php
        $str = str_repeat('a', 4096);
        for ($i=0; $i<8; $i++) {
                echo $str;
        }
?>

With Apache 2 filter I was able to send between 150-167 requests per second, 
each request comprising of header 270 bytes and content 32768 bytes, with a 
Net I/O: 4895.8 KB/s. The increase in perfromance can be explained by a 
significantly lower number of calls to the output function and tunning the 
output to benefit the most from output buffering.

Same test with Apache 2 handler resulted in:

Request rate: 132.0 req/s (7.6 ms/req)
Reply rate [replies/s]: min 117.4 avg 132.0 max 152.3
Net I/O: 3915.6 KB/s
CPU time [s]: user 7.63 system 38.92 (user 10.1% system 51.4% total 61.5%)


All tests were conducated 10 times a piece and a total of 10000 requests were 
sent during each test instance.

Ilia