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

Performance Tuning by Tweaking Apache Configuration

Correct configuration of the MinSpareServers, MaxSpareServers,
StartServers, MaxClients, and MaxRequestsPerChild parameters is very
important. There are no defaults. If they are too low, you will under-use
the system’s capabilities. If they are too high, the chances are that the
server will bring the machine to its knees.

Correct configuration of the MinSpareServers, MaxSpareServers,
StartServers, MaxClients, and MaxRequestsPerChild parameters
is very important. There are no defaults. If they are too low, you
will under-use the system’s capabilities. If they are too high, the
chances are that the server will bring the machine to its knees.

All the above parameters should be specified on the basis of the
resources you have. With a plain apache server, it’s no big deal if
you run many servers since the processes are about 1Mb and don’t eat a
lot of your RAM. Generally the numbers are even smaller with memory
sharing. The situation is different with mod_perl. I have seen
mod_perl processes of 20Mb and more. Now if you have MaxClients
set to 50: 50x20Mb = 1Gb. Do you have 1Gb of RAM? Maybe not. So how
do you tune the parameters? Generally by trying different
combinations and benchmarking the server. Again mod_perl processes
can be of much smaller size with memory sharing.

Before you start this task you should be armed with the proper weapon.
You need the crashme utility, which will load your server with the
mod_perl scripts you possess. You need it to have the ability to
emulate a multiuser environment and to emulate the behavior of
multiple clients calling the mod_perl scripts on your server
simultaneously. While there are commercial solutions, you can get
away with free ones which do the same job. You can use the
ApacheBench utility which comes with the Apache distribution, the
crashme script which uses LWP::Parallel::UserAgent, httperf or
http_load all discussed in one of the previous articles.

It is important to make sure that you run the load generator (the
client which generates the test requests) on a system that is more
powerful than the system being tested. After all we are trying to
simulate Internet users, where many users are trying to reach your
service at once. Since the number of concurrent users can be quite
large, your testing machine must be very powerful and capable of
generating a heavy load. Of course you should not run the clients and
the server on the same machine. If you do, your test results would be
invalid. Clients will eat CPU and memory that should be dedicated to
the server, and vice versa.

Configuration Tuning with ApacheBench

I’m going to use ApacheBench (ab) utility to tune our server’s
configuration. We will simulate 10 users concurrently requesting a
very light script at http://www.example.com/perl/access/access.cgi.
Each simulated user makes 10 requests.

  % ./ab -n 100 -c 10 http://www.example.com/perl/access/access.cgi

The results are:
  Document Path:          /perl/access/access.cgi
  Document Length:        16 bytes

  Concurrency Level:      10
  Time taken for tests:   1.683 seconds
  Complete requests:      100
  Failed requests:        0
  Total transferred:      16100 bytes
  HTML transferred:       1600 bytes
  Requests per second:    59.42
  Transfer rate:          9.57 kb/s received
  Connnection Times (ms)
                min   avg   max
  Connect:        0    29   101
  Processing:    77   124  1259
  Total:         77   153  1360

The only numbers we really care about are:
  Complete requests:      100
  Failed requests:        0
  Requests per second:    59.42