Administrators and developers panic if a site is strained by the sheer number of visitors – the web shop collapses under the onslaught of customers and only the disk LEDs show signs of life. At those moments, many a thoughtful admin wishes they had taken the time for a stress test.

It is good practice to subject web applications to an extensive load test to avoid unfortunate surprises during production. Only through testing can application developers and responsible webmasters reliably determine which features perform well and which don't.

The Apache Software Foundation offers a very mature application called JMeter [1] as a tool for testing websites. Stefano Mazzocchi, born in Italy and now employed at Google in the US, began to develop JMeter in 1998 in order to complete load tests on the Apache Tomcat server. Mazzocchi, who has been a member of the Apache Jakarta Project Management Committee (PMC) since 1999, then carried on with the tool as a Jakarta sub-project. JMeter, which occupies a niche similar to the Grinder 3 testing tool [2], has been an independent Apache top-level project since 2011.

Several versions of JMeter are released each year. The current version, JMeter 2.13, supports the HTTP, SOAP, FTP, JDBC, MongoDB, LDAP, JMS, AJP, TCP, SMTP, POP3, and IMAP protocols, as well as their encrypted counterparts.

The JMeter documentation specifies a Java Runtime Environment (JRE, at least version 6, but also 8) and appropriate drivers. Pre-configured templates for popular web applications, such as WordPress, are available on the Internet [3], and you can expand JMeter functionality using scripts in different programming languages and plugins [4].

More on JMeter

JMeter is designed to simulate the effect of real web traffic. The traffic appears to the web server as a rush of incoming connections from browsers on the network. JMeter supports many common web protocols, and a helpful GUI makes it easy to configure, organize, and launch new tests. The user has a range of options for displaying output graphically for easy analysis.

Although JMeter might appear as a browser to the web server, the documentation points out that "JMeter is not a browser." According to the project website, "JMeter looks like a browser (or rather, multiple browsers); however, JMeter does not perform all the actions supported by browsers. In particular, JMeter does not execute the JavaScript found in HTML pages. Nor does it render the HTML pages as a browser does (it's possible to view the response as HTML etc., but the timings are not included in any samples, and only one sample in one thread is ever viewed at a time)." JMeter is an effective testing tool in spite of these limitations, but you'll need to be aware of what it does and doesn't do to interpret the results.

Taking Action with a Test Plan

You can call JMeter using the jmeter.sh script in the $JMETER_HOME/bin directory. Look in the same directory for the jmeter.log logfile, which you should analyze if errors occur.

The procedure for a JMeter test is defined through a test plan. Start with the templates in the bin/templates or printable_docs/demos directories and customize the templates as desired. Choose Templates in the JMeter File menu and select Building a Web Test Plan from the available templates. The example template sets two requests for the jmeter.apache.org host and the / and /changes.html pages and displays the result as a graph.

The other way to build a test plan is to create one from scratch. Test plans are written in XML format without an XSD schema. You can, however, convert the plan into HTML for documentation via a style sheet:

extras/schematic.cmd <Testplan>.jmx

A recorder supplied with JMeter is the third and most convenient method for creating a test script. First enter the JMeter server proxy address in your web browser with port 8888 and localhost; then, call up the template for the test script recorder and start it. Now record all calls the user completes in the browser. You can manually add the test script recorder element to the icon workbench using Add | Non-Test Elements | HTTP(S) Test Script Recorder. This technique is particularly useful for more complex page visits with registration.

Once the recording is complete, you can add variables to adapt it for different environments and hostnames (Figure 1).

Figure 1: A simple web test plan with configuration elements.

Expanding Test Plans

JMeter creates simulated users in thread groups and gives you the option of defining warm-up or waiting times. The actual queries are called samplers. The simulated users can work with cookies, navigate logins, and fill in forms. Testers should verify the success of the results to distinguish between technical and professional errors.

Logic controllers manage the execution of individual parts of the test plan. Listener elements illustrate the test results as graphs or tables (Figure 2). The tester can specify parameters as customized configuration elements (User Defined Variables) at the beginning of the test plan or give them to JMeter as environment parameters. The great art is in designing the test plan so you can expand and configure it easily [5].

Figure 2: The result graph of an advanced web test plan.