Improving mod_perl Driven Site's Performance -- Part VII: Performance Tuning by Tweaking Apache Configuration
Download the authoritative guide: Data Center Guide: Optimizing Your Data Center Strategy
Download the authoritative guide: Cloud Computing: Using the Cloud for Competitive Advantage
Correct configuration of the
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
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.
I'm going to use
ab) utility to tune our server's
configuration. We will simulate 10 users concurrently requesting a
very light script at
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 bytesConcurrency 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 receivedConnnection 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
IT Solutions Builder TOP IT RESOURCES TO MOVE YOUR BUSINESS FORWARD
Which topic are you interested in?
What is your company size?
What is your job title?
What is your job function?
Searching our resource database to find your matches...