Website benchmarking is a very challenging task to get correct, with useful results. This chapter will discuss a simple way to benchmark your Drupal website. The method discussed here is just one way to benchmark, but whatever process you use to benchmark your Drupal website, be consistant. Don't try to compare performance numbers between different benchmarking programs or processes.
Some developers will benchmark their site only on the unauthenticated home page. This approach really isn't all that indicative of overall site performance. Our approach to benchmarking is to use awstats to see what are the top 4 or 5 URLs accessed on your server. If you don't know which URLs could be popular, we suggest picking the 4 or 5 most complex, or largest URLs in your Drupal site. Keep in mind that many more smaller URLs called more frequently can perform differently than 4 or 5 URLs called less frequently.
The directions below are for an unauthenticated Drupal user, which is fine for a brochure type Drupal site. ThetaJoin will update this chapter to include benchmarking authenticated users too.
http_load is ThetaJoin's favorite benchmarking program. There are others out there, but we find http_load to very simple to use, with the exact features needed to benchmark your Drupal site. Other benchmarking suites can be very complex to set up.
From the http_load homepage:
http_load runs multiple http fetches in parallel, to test the throughput of a web server. However unlike most such test clients, it runs in a single process, so it doesn't bog down the client machine. It can be configured to do https fetches as well.
You give it a file containing a list of URLs that may be fetched, a flag specifying how to start connections (either by rate or by number of simulated users), and a flag specifying when to quit (either after a given number of fetches or a given elapsed time). There are also optional flags for checksums, throttling, random jitter, and progress reports.
Sample run:
% ./http_load -rate 5 -seconds 10 urls
49 fetches, 2 max parallel, 289884 bytes, in 10.0148 seconds
5916 mean bytes/connection
4.89274 fetches/sec, 28945.5 bytes/sec
msecs/connect: 28.8932 mean, 44.243 max, 24.488 min
msecs/first-response: 63.5362 mean, 81.624 max, 57.803 min
HTTP response codes:
code 200 -- 49
See the manual entry for more details.
The main goal of a proper benchmark is to run your tests as close as possible to real usage of your Drupal website. It's too easy to benchmark in ways that don't match your site's actual usage.
Pages per second is just one number in a complex measurement. To see how well your website is performing internally, run http_load over all of your Drupal site's URLs. You can use ThetaJoin performance monitoring to see how well the webserver, MySQL database, and Ubuntu server are performing.
When benchmarking your ThetaJoin server from a single IP address, you need to know that above a certain threshold, your ThetaJoin server will think it's under Denial of Service (DOS) attack. This causes the server to "throttle back" its performance. To get a more accurate http_load benchmark, launch http_load from multiple workstations that have different IP addresses.