When developing or deploying a website or web application, performance testing matters, and that’s exactly what HTTPerf offers! Measuring is also one of the pillars of a good DevOps approach.
What is HTTPerf?
It’s an open source tool for performance testing (benchmarking), and more specifically load testing. When you deploy a site to production, it’s worth putting your server through a few tests.
How does HTTPerf work?
It’s very simple, which is exactly why I’m presenting it. In the world of load testing, there are several types of tests.
HTTPerf simply sends a large number of HTTP requests to the target web server and counts the responses. It’s one way of measuring how much load a server can handle.
The goal is simple: fire lots of requests at a URL and gradually increase the load to see when the response rate drops below 100% (the ideal availability rate for a server). That tells you the maximum number of HTTP connections your server can handle.
How to install HTTPerf
I can’t cover every operating system, but I’ve installed HTTPerf on Debian and Windows.
On Debian (and Ubuntu):
sudo apt-get install httperfOn Windows:
I found this link: https://itefix.net/httperf
For other systems:
Here’s the GitHub link: https://github.com/httperf/httperf
A GitHub link always comes in handy: if installation on Debian or Windows doesn’t go smoothly, you can always compile the program from source.
How to use HTTPerf
I’ll use HTTPerf on my Debian machine, but you should be able to follow along.
As usual, this isn’t a complete tutorial, just a taste to make you want to explore the tool further.
Basic load test
Disclaimer: running these tests against servers you don’t own is forbidden. To test your hosting provider’s server, for example, ask for permission first; you can never be too careful. Here, all tests run against my local web server, but nothing stops you from setting up a small server on a Raspberry Pi to make things more interesting.
httperf --server localhost --port 80 --uri / --num-conns 10000httperf is the program name, and the –server argument specifies the target hostname. Note that it defaults to “localhost”, so specifying it isn’t strictly necessary here.
The –port argument is self-explanatory: it sets the port to use. The default is 80, so it isn’t needed either.
The –uri argument specifies the resource to load test, for example “/index.html”. Here, I want the root, i.e. http://localhost/
Finally, the –num-conns argument sets the number of connections to make.
Here’s the output in my case:
httperf --client=0/1 --server=localhost --port=80 --uri=/ --send-buffer=4096 --recv-buffer=16384 --num-conns=10000 --num-calls=1
httperf: warning: open file limit > FD_SETSIZE; limiting max. # of open files to FD_SETSIZE
Maximum connect burst length: 1
Total: connections 10000 requests 10000 replies 10000 test-duration 11.865 s
Connection rate: 842.8 conn/s (1.2 ms/conn, <=1 concurrent connections)
Connection time [ms]: min 0.7 avg 1.2 max 8.7 median 1.5 stddev 0.3
Connection time [ms]: connect 0.0
Connection length [replies/conn]: 1.000
Request rate: 842.8 req/s (1.2 ms/req)
Request size [B]: 62.0
Reply rate [replies/s]: min 840.5 avg 846.7 max 852.9 stddev 8.8 (2 samples)
Reply time [ms]: response 1.1 transfer 0.0
Reply size [B]: header 172.0 content 2567.0 footer 0.0 (total 2739.0)
Reply status: 1xx=0 2xx=10000 3xx=0 4xx=0 5xx=0
CPU time [s]: user 5.02 system 6.84 (user 42.3% system 57.6% total 100.0%)
Net I/O: 2305.4 KB/s (18.9*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 0Although all of this is interesting, here are the key values:
– 10,000 requests received 10,000 replies
– The test lasted 11.865 s
– We made 842.8 connections per second, and therefore 842.8 requests per second
– There were no errors
Advanced load test
As mentioned, the goal is to find your server’s limits. A few extra arguments help you find the maximum load.
httperf --server localhost --port 80 --uri / --num-conns 10000 --rate 500 --hog --timeout 5This command isn’t the most complex, but it lets you play with more parameters.
The –rate argument sets the number of requests per second. Note that if your machine can’t exceed 800 requests/s, setting a –rate of 900 is pointless.
The –hog argument opens as many TCP ports as possible. Without it, the available port range is 1024 to 5000. For a real test, this argument is recommended.
Finally, the –timeout argument sets the number of seconds before a request is considered unanswered. The default –timeout is 5, so it isn’t strictly needed here.
HTTPerf: conclusion
To sum up, HTTPerf is a very basic tool, and that’s what won me over.
I encourage you to read the full manual (https://itefix.net/httperf-man-page) to see that, despite its simplicity, it accepts many more arguments to do more.
If you want to go further with load testing and benchmarking, HTTPerf won’t be enough. There are plenty of other ways to test, which I hope to cover soon, such as long-running stress tests to detect memory leaks and the like. Many sites also interact with users, so you’ll need tests with more interactions (login, content uploads, etc.).
Resource for building httperf: https://easyengine.io/tutorials/benchmark/httperf/
Have fun!
Leave a Reply