I’ve been knee deep in performance and scalability for some time now, and have used and learned of many useful tools and techniques to help out. One of my favorite command line tools for seeing how well a single Apache server is churning out pages in development comes stock on Ubuntu, and Mac OS X:Apache Benchmark.
A simple performance test against the homepage of one of my client site’s using AB at the command line:
ab -t5 -n100 http://magentohostsolution.com
This is ApacheBench, Version 2.3 <$Revision: 655654 $> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking magentohostsolution.com (be patient) Finished 664 requests Server Software: Apache/2.2.8 Server Hostname: www.teamgzfs.com Server Port: 80 Document Path: / Document Length: 306 bytes Concurrency Level: 100 Time taken for tests: 5.054 seconds Complete requests: 664 Failed requests: 0 Write errors: 0 Total transferred: 465003 bytes HTML transferred: 205326 bytes Requests per second: 131.38 [#/sec] (mean) Time per request: 761.143 [ms] (mean) Time per request: 7.611 [ms] (mean, across all concurrent requests) Transfer rate: 89.85 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 38 78 48.7 64 994 Processing: 114 540 226.2 493 1690 Waiting: 114 531 205.6 493 1485 Total: 191 618 236.0 558 1808 Percentage of the requests served within a certain time (ms) 50% 558 66% 587 75% 598 80% 617 90% 845 95% 1163 98% 1402 99% 1746 100% 1808 (longest request)
There is quite a bit of useful information here that can help you tune your code and server. It’s important to note however, that when working on a larger site, that expects quite a bit more traffic, you might want to investigate some more thorough solutions outside of just a single machine and ab. It is, however, a nice starting point into useful information.
One rather funny pitfall you can run into however, is if the host you are sending requests to is smartly secured – these types of tests become a bit useless, as they may have security settings to limit or delay requests – providing you with timeouts and/or inaccurate information. Best to run these types of things in a semi-developmental mode with those types of security settings turned down, and rely on bigger guns or fleets of boxes and scripts to hit a production secure site.
In addition to hitting just a landing page, you can use AB to send COOKIE or POST data too! This is very useful if you want to see how pages perform but need credentials to get in first. This is a little trickier to do using the -c, -T, -p, and -v flags. I noticed there are under-useful resources online to figuring it out with AB, so it would seem worthwhile to write it – as it took me some trickery to figuring it out as well:
Sending POST data to a login form:
First we create a file that contains our URL encoded post data. Note, AB expects the values to be URL encoded, but not the equal (=) or ampersands (&).
Capturing a cookie:
Here, we use the verbosity (-v) flag so we can see the response headers that come back — many sites will send back a cookie once authenticated, we’ll want to capture that cookie here. Though, some sites will not require it, I demonstrate it for the sake of example:
ab -v4 -n1 -T 'application/x-www-form-urlencoded' -p post_data.txt http://www.foobar.com/login
The returned response header will fly by quick, you’re looking for something like the following:
The session data may come back encrypted, unencrypted, a serialization, or just a number. That varies by site. The point here is you have a key/value pair for the cookie. All you need is the part up to the semi-colon ( not including the semi-colon ). Copy that “key=val” string, and use it when hitting other pages on the site you are testing, ie:
Using a cookie to test a page that requires a cookie:
ab -t10 -n100 -c 'somessession=somerandomsessiondata' http://www.foobar.com/login_required_page
This can become a lot of fun once you get the hang of it.