Improving mod_perl Driven Site’s Performance — Part VII: Performance Tuning by Tweaking Apache Configuration Page 3

  HW: RS6000, 1Gb RAM
  SW: AIX 4.1.5 . mod_perl 1.16, apache 1.3.3
  Machine running only mysql, httpd docs and mod_perl servers.
  Machine was _completely_ unloaded during the benchmarking.

After each server restart when I changed the server's configuration, I

made sure that the scripts were preloaded by fetching a script at

least once for every child.

It is important to notice that none of the requests timed out, even if

it was kept in the server's queue for more than a minute!  That is the

way ab works, which is OK for testing purposes but will be

unacceptable in the real world - users will not wait for more than

five to ten seconds for a request to complete, and the client

(i.e. the browser) will time out in a few minutes.

Now let's take a look at some real code whose execution time is more

than a few milliseconds.  We will do some real testing and collect the

data into tables for easier viewing.

I will use the following abbreviations:
  NR    = Total Number of Request
  NC    = Concurrency
  MC    = MaxClients
  MRPC  = MaxRequestsPerChild
  RPS   = Requests per second

Running a mod_perl script with lots of mysql queries (the script under

test is mysqld limited)

(http://www.example.com/perl/access/access.cgi?do_sub=query_form),

with the configuration:
  MinSpareServers        8
  MaxSpareServers       16
  StartServers          10
  MaxClients            50
  MaxRequestsPerChild 5000

gives us:
     NR   NC    RPS     comment
  ------------------------------------------------
     10   10    3.33    # not a reliable figure
    100   10    3.94    
   1000   10    4.62    
   1000   50    4.09

Conclusions: Here I wanted to show that when the application is

slow (not due to perl loading, code compilation and execution, but

limited by some external operation) it almost does not matter what

load we place on the server.  The RPS (Requests per second) is almost

the same.  Given that all the requests have been served, you have the

ability to queue the clients, but be aware that anything that goes

into the queue means a waiting client and a client (browser) that

might time out!

Now we will benchmark the same script without using the mysql (code

limited by perl only):

(http://www.example.com/perl/access/access.cgi), it's the same

script but it just returns the HTML form, without making SQL queries.

  MinSpareServers        8
  MaxSpareServers       16
  StartServers          10
  MaxClients            50
  MaxRequestsPerChild 5000
     NR   NC      RPS   comment
  ------------------------------------------------
     10   10    26.95   # not a reliable figure
    100   10    30.88   
   1000   10    29.31
   1000   50    28.01
   1000  100    29.74
  10000  200    24.92
 100000  400    24.95

Conclusions: This time the script we executed was pure perl (not

limited by I/O or mysql), so we see that the server serves the

requests much faster.  You can see the number of requests per second

is almost the same for any load, but goes lower when the number of

concurrent clients goes beyond MaxClients.  With 25 RPS, the

machine simulating a load of 400 concurrent clients will be served in

16 seconds.  To be more realistic, assuming a maximum of 100

concurrent clients and 30 requests per second, the client will be

served in 3.5 seconds.  Pretty good for a highly loaded server.