Using a different threaded test tool that compares the actual output to
an expected output, I ran 150k tests with a 100% pass rate. This is with
20 concurrent request threads. To handle the load I added this to my config:

ns_param    maxthreads     512
ns_param    minthreads     10

I am running PHP 5.0.0, AOLserver 4.0.5 on Linux 2.4.24 (RedHat 7.2).

rob

Dossy Shiobara wrote:
On 2004.07.23, Noah Robin <[EMAIL PROTECTED]> wrote:

So, in the interest of science (and probably masochism) I compiled PHP
4.3.8 (with the aolserver.c patch from panoptic) against aolserver
3.5.10 and 4.0.7 last night, and ran some load tests. Result: on linux
2.4.26, and the only PHP configure option was --with-aolserver=, I was
seeing a failure rate of ~6% for a page that only called phpinfo().

Load test:  /usr/sbin/ab2 -n100000 -c25 http://localhost:8000/ (ab2
being the version of 'ab' that ships with apache2).


Lets see what I get on my system:

    $ uname -a
    Linux ecwav 2.6.5 #3 Thu May 6 06:57:14 EDT 2004 i686 GNU/Linux

    $ cat /proc/cpuinfo | grep "model name"
    model name      : Intel(R) Pentium(R) III CPU family      1266MHz

    $ cat test.php
    <? phpinfo(); ?>

    $ ab -c25 -n10000 http://panoptic.com/test.php
    This is ApacheBench, Version 1.3d <$Revision: 1.67 $> apache-1.3
    Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Copyright (c) 1998-2002 The Apache Software Foundation, http://www.apache.org/

    Benchmarking panoptic.com (be patient)
    Completed 1000 requests
    Completed 2000 requests
    Completed 3000 requests
    Completed 4000 requests
    Completed 5000 requests
    Completed 6000 requests
    Completed 7000 requests
    Completed 8000 requests
    Completed 9000 requests
    Finished 10000 requests
    Server Software:        AOLserver/4.0.7
    Server Hostname:        panoptic.com
    Server Port:            80

    Document Path:          /test.php
    Document Length:        23519 bytes

    Concurrency Level:      25
    Time taken for tests:   30.294 seconds
    Complete requests:      10000
    Failed requests:        3
       (Connect: 0, Length: 3, Exceptions: 0)
    Broken pipe errors:     0
    Total transferred:      236933670 bytes
    HTML transferred:       235213498 bytes
    Requests per second:    330.10 [#/sec] (mean)
    Time per request:       75.73 [ms] (mean)
    Time per request:       3.03 [ms] (mean, across all concurrent requests)
    Transfer rate:          7821.14 [Kbytes/sec] received

    Connnection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        0    45  370.0      0  9012
    Processing:     3    26  139.5     17  6325
    Waiting:        0    26  139.5     17  6325
    Total:          3    71  398.6     17  9031

    Percentage of the requests served within a certain time (ms)
      50%     17
      66%     18
      75%     19
      80%     21
      90%     29
      95%     33
      98%    355
      99%   3022
     100%   9031 (last request)

    PHP 4.3.7RC1



This failure rate is obviously not going to cut it for production use,
and I was wondering if anyone had seen this before. Nothing in the
server.log file during the failures; the access log shows that
sometimes the request simply returned zero-length content. Thread
stack-size has been set to 1M. Anyone seen this before? =)


Hmm, in my test above, we see 3 failures out of 10,000 -- 0.03% -- is
probably reasonable for a production site.  Nothing emitted into the
server log, nor the php4.log either.

Let me crank up ab to -v99 and see if I can get the failures to happen
again ...

    Failed requests:        2
       (Connect: 0, Length: 2, Exceptions: 0)

OK, so it happened again.  Looking at the log ... nothing enlightening.

Lets ask Google.  It knows everything ...

Aha.  OK -- those "Length" errors can *probably* be ignored --
ApacheBench registers a "Length" failure if the HTTP response length
varies from the initial response, which it CAN do for the test.php page
that calls phpinfo(), since the output can vary.  Look in the "PHP
Variables" section towards the bottom of the page at
_SERVER["REMOTE_PORT"] -- as it goes from 9999 to 10000, the length of
the document goes up by 1 byte causing a length failure.  Same thing
happens in the other direction, as it goes from 32000 back down to
1000-something.


I agree with you, a true 6% failure rate is unacceptable. On my test environment, I'm seeing effectively a 0% failure rate.

-- Dossy

--
Dossy Shiobara                       mail: [EMAIL PROTECTED]
Panoptic Computer Network             web: http://www.panoptic.com/
  "He realized the fastest way to change is to laugh at your own
    folly -- then you can let go and quickly move on." (p. 70)


-- AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of 
your email blank.

Reply via email to