http_load - another webserver peformance tester

Http_load is another cool webserver performance tester that gives simple stats on how your webapp is performing.

How to install in OS X

1. Download from http://www.acme.com/software/http_load/
2. Open terminal, cd to the directory where the archive is and unzip
   $ tar xvzf http_load-12mar2006.tar.gz

3. Move to that directory
   $ cd http_load-12mar2006
4. Run
   $ make
5. Run
   $ sudo make install

You’re ready! Open up a text editor and write down the website’s url you want to test (your own preferably), then cd to the directory where the .txt is and run
$ http_load -parallel 5 -fetches 100 name_of_file.txt
which means open 5 concurrent connections and fetch the webpage 100 times.

You’ll get something like this:

100 fetches, 5 max parallel, 1.34237e+07 bytes, in 15.842 seconds
134237 mean bytes/connection
6.31234 fetches/sec, 847351 bytes/sec
msecs/connect: 28.9069 mean, 75.011 max, 14.865 min
msecs/first-response: 435.84 mean, 2484.28 max, 96.082 min
93 bad byte counts
HTTP response codes:
code 200 — 100

I highlighted the important bits. At the moment the webserver is capable of handling 6 requests per second and has a mean average initial latency of 435 milliseconds.

Http_load tells you how your webapp is currently performing allowing you to test it under different conditions, basically it’s a benchmarking tool juts like httperf i covered here. The next step is optimization. Have a look at the 1st part of  Getting Rich with PHP 5 (what a crappy title) by rasmus lerdorf  for tools you can use to profile your code and some tips on optimization. In the example shown he goes from 17 reqs/sec to 1100 reqs/sec .

measuring webserver performance - httperf

Httperf is a webserver performance tester. There are loads of performance testers out there (take a look here ) but i was up and running with httperf in no time. So here’s a quick get started guide

1. Download the latest version from ftp://ftp.hpl.hp.com/pub/httperf/
2. Install
   • $ tar xvzf httperf-0.9.0.tar.gz
   • $ cd httperf-0.9
   • $ ./configure
   • $ make
   • $ sudo make install

   Httperf is installed by default in /usr/local/bin/httperf. You then invoke httperf from the command line.

3. Have a website to test (lol)
4. Here’s a sample command
   $ httperf –server hostname –port 80 –ur /test.html –rate 150 –num-conn 27000 –num-call 1  –timeout 5
   Example: You have your site on localhost and for now just wanna test that.
   • $ httperf –server localhost –ur /about.html –num-conns 1000
     - test the page about.html in the localhost  server making 1000 concurrent connections
   • $ httperf  –-server=localhost –-wsess=12,8,2 –-rate=1 –-timeout=5
     • The –wsess sets the total number of sessions to generate, the number of calls per session, and the time (in seconds) that separates consecutive calls. If we use –wsess=12,8,2, we’re setting 12 sessions at five calls per session with two seconds between each call.
     • The –rate switch specifies the number of HTTP requests/second sent to the Web server — indicates the number of concurrent clients accessing the server. [Update] Actually when used together with –wsess it specifies the number of sessions and not of requests -> see comment by John Wilkinson below
     • The –timeout switch sets the maximum number of seconds to wait for a server response before httperf gives up. The default is forever so it’s good practice to set it just in case the server hangs (hangings your resources also). If this timeout expires, httperf considers the corresponding call to have failed.
     • The –num-conn sets how many total HTTP connections will be made during the test run - this is a cumulative number, so the higher it is, the longer the test runs
5. Analyze the statistics printed to the console.
   There are six groups of statistics: overall results, results pertaining to the TCP connections, results for the requests that were sent, results for the replies that were received, CPU and network utilization figures, as well as a summary of the errors that occurred.
   Example printout:
   “Maximum connect burst length: 1
   Total: connections 100 requests 100 replies 100 test-duration 16.385 s

   Connection rate: 6.1 conn/s (163.8 ms/conn, <=1 concurrent connections)
   Connection time [ms]: min 135.5 avg 163.8 max 406.4 median 159.5 stddev 37.4
   Connection time [ms]: connect 19.0
   Connection length [replies/conn]: 1.000

   Request rate: 6.1 req/s (163.8 ms/req)
   Request size [B]: 64.0

   Reply rate [replies/s]: min 5.8 avg 6.1 max 6.2 stddev 0.2 (3 samples)
   Reply time [ms]: response 74.1 transfer 70.8
   Reply size [B]: header 514.0 content 15405.0 footer 1.0 (total 15920.0)
   Reply status: 1xx=0 2xx=100 3xx=0 4xx=0 5xx=0

   CPU time [s]: user 3.52 system 12.78 (user 21.5% system 78.0% total 99.5%)
   Net I/O: 95.3 KB/s (0.8*10^6 bps)

   Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0
   Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0
   “

The connection rate, the request rate and the reply rate are the ones to look at. The better a website is performing (at the rate requested) the closer the connection and reply rate rate will be to the request rate specified in the initial command (–rate). Normally you do a series of tests, always increasing the request rate until you start to see that the reply and connection rate are no longer keeping up - that’s when you’ve hit your boundary, ie. how many requests per second your webapp is able to handle.

Also check autobench for automation of the testing process, here for an example of how httperf was used to benchmark the evolution of a project, an article from the source httperf—A Tool for Measuring Web Server Performance and finally this peepcode looks interesting.

Anyway, if i’ve missed any important information please say so in the comments.

[Update] Ted Bullock, one of the developers of httperf, was kind enough to point me to his quickstart guide, a six page long doc which has much more detailed information :=)

the illuminatti

The illuminatti is an art project that explores the mesmerizing power everyday technology has on us. The modern deity is then technology. In his own words, Evan Baden the author explains it:

In Westernized cultures today, there is a generation that is growing up without the knowledge of what it is to be disconnected. The world in which we are growing up is always on. We are continuously plugged in, and linked up. We take this technology for granted. Not because we are ungrateful, but because we simply don’t know a world without it.

From our earliest memories, there has always been a way to connect with others, whether it is Myspace, Facebook, cell phones, e-mail, or instant messenger. And now, with the Internet, instant messaging, and e-mail in our pocket, right there with our phones, we can always feel as if we are part of a greater whole. These devices grace us with the ability to instantly connect to others, and at the same time, they isolate us from those with whom we are connected. They allow for great freedom, yet so often, we are chained to them. They have become part of who we are and how we identify ourselves. These devices ordain us with a wealth of knowledge and communication that would have been unbelievable a generation ago. More and more, we are bathed in a silent, soft, and heavenly blue glow. It is as if we carry divinity in our pockets and purses.