- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
Staying Out of Deep Water: Performance Testing Using HTTPD-Test's Flood
Once you've set up your server and users are accessing your Web site, the last thing you want to hear about are performance problems with the site. You can test the system manually, but there are limitations to manual-based testing. So you've set up your server and users are accessing your Web site; the last thing you want are performance problems with the site. If only you could have tested for them before going live. With the Flood component of the Apache HTTP Project's HTTPD-Test (so named because it floods an HTTP server with requests to test its response times) you can. Martin Brown explains how to install and configure Flood, and offers some real world scenarios.
One major downside of manual testing (aside from the time investment) is that it doesn't reveal where the real problem with the site lies. Is it a configuration problem with the server, a problem with some dynamic elements, or a more fundamental network performance issue?
The Apache HTTP Project includes a sub-project called HTTPD-Test. As the name suggests, it's a test suite for Apache and HTTP in general. The suite contains a number of different elements, and this article will focus on the one known as Flood. Flood is so named because it is used to flood an HTTP server with requests to test its response times.
Flood uses an XML document with the necessary settings -- URLs and optional POST data -- to send requests to a given server or range of servers. Flood then measures the time it takes to:
- Open the socket to the server
- Write the request
- Read the response
- Close the socket
With these four criteria being measured, administrators can identify whether the problem is with the Apache configuration (or any other HTTP server), the sheer load and performance of the hardware, or a network bottleneck.
You can download the packages -- httpd-test and apr/apr-util -- required for building from the CVS server at Apache. You'll need to log in first though (the password is 'anoncvs'):
$ cvs -d :pserver:email@example.com:/home/cvspublic login $ cvs -d :pserver:firstname.lastname@example.org:/home/cvspublic co httpd-test/flood $ cd httpd-test/flood $ cvs -d :pserver:email@example.com:/home/cvspublic co apr $ cvs -d :pserver:firstname.lastname@example.org:/home/cvspublic co apr-util
Once you have the source, you must build and compile the application using:
$ buildconf $ configure $ make all
You're now ready to go!