JMeter is easy to install. It can be downloaded from http://jmeter.apache.org/. The site provides an archive in the .tgz and .zip formats. You can download either of them and extract them to a location. At the time of writing the book, version 2.12 is the latest version available to download.

The extracted archive will have the following structure:

Before we can start running JMeter, we need to make sure that Java is available on the box.

JMeter requires a Java runtime to be available. The runtime version has to be 6 or above. Check whether Java is available using the following code:

$ java --version

If Java is not available, install the OpenJDK runtime available using apt-get:

$ sudo apt-get update
$ sudo apt-get install default-jdk

This will install OpenJDK on the box. However, if you want to install Oracle JDK, you have to use the following commands:

$ sudo apt-get install python-software-properties
$ sudo add-apt-repository ppa:webupd8team/java
$ sudo apt-get update

This will install a third-party apt-get repository, from where the package will be installed as Oracle does not provide a repository for this. Now, you can install JDK using the following command:

$ sudo apt-get install oracle-java6-installer

Setting JAVA_HOME

Once a version of Java is installed on the box, you need to set the JAVA_HOME environment variable. This can be done by finding the path of the Java installation and then adding the variable to /etc/environment.

Determine the Java location using update-alternatives as follows:

$ sudo update-alternatives --config java

This lists all the Java installations available on your box, as shown in the following output:

Copy the path from your preferred installation, and then edit /etc/environment to add JAVA_HOME variable:

JAVA_HOME="YOUR_PATH"

Now, reload the /etc/environment configuration:

$ source /etc/environment

Verify the change by executing the following command:

echo $JAVA_HOME

The bin folder in the JMeter installation offers all the scripts to run it. The tool can be executed in any of the following modes:

GUI mode:

Non-GUI mode:

Server mode:

If your network has proxy server settings, then you may want to pass this additional information to the JMeter engine. In order to do so, use the following options:

JMeter tests are composed of several elements. These elements are responsible for making requests, verifying responses, doing analyses, generating graphs, simulating loads, and so on. Similar types of elements are grouped together to define JMeter components. In the following section, we will discuss the important components required to build a test.

In order to define a test, we need to build requests and validate and analyze the response received. Instead of adding HTTP request samplers, we can run a proxy server, packed in JMeter, and record all samples.

Let's start building a simple test plan by starting JMeter in GUI mode, as shown here:

The next step is to start the proxy server and point the browser to it. The option is available under Workbench. Navigate to Workbench and right-click on Add | Non Test Elements | HTTP(S) Test Script Recorder.

Take a note of the port on which the proxy server will run; by default, it will run on 8080. Click on Start to run the server, as shown here:

The proxy server is now running on 127.0.0.1:8080. Apply these settings in your browser under Network | Settings. The following screenshot is the result of these steps:

Now, when you open a web page in the browser, the request will be recorded in JMeter. We will use these recorded requests to generate our test plan. Access the Hello world! page developed in the previous chapter using the IP address of your machine, for example, http://192.168.2.100/hello/. This will record requests in the JMeter proxy server, which we will use in our tests.

JMeter tests are grouped as users, so add Thread Group under Test Plan by navigating to Test Plan and right-clicking on Add | Threads | Thread Group.

The Thread Group element has a couple of useful fields. The fields for Number of Threads, Loop Count, and Ramp up Period can be used to simulate the required load.

Now, select and drag all the requests generated under HTTP Test Recorder to Thread Group. This adds the selected requests to the test.

The test needs to verify and analyze the responses received for the requests initiated. To see the complete list, navigate to Thread Group and right-click on Add | Assertions.

For our purposes, we will use the Response Assertion component. The panel enables us to compare various fields of the response. Using this, we can verify the response text, response code, response headers, and so on.

Add Response Assertion under all requests using the right-click options. In each of the assertions, select Response Code and add 200 under Patterns To Test.

We need to control timeouts to determine the error rate and the throughput. For each request, JMeter allows us to set a connection timeout and a response timeout. The HTTP Request component contains fields for both of these options. Optionally, we could add the Http Requests Defaults component available upon navigating to Thread Group and right-click on Add | Config Element. The values defined in this component will remain the same for all requests. As in Siege, put a small value in the connection timeout as well as the response timeout:

Next, to analyze the result, we need to add Listener by right-clicking on Add options on Thread Group. For our purposes, we will use the Aggregate Report component. The component aggregates the response information and provides the request count, minimum, maximum, average, error rate, approximate throughput (request/second), and kilobytes per second for each request.

Along with the Aggregate Report component, add the View Results Tree component. The component will show all responses in the form of a tree. It also allows you to inspect response codes, the time taken, headers, and so on. The component can selectively show errors, success messages, or all requests. It is quite helpful to get error requests in the component as you can analyze the response to see what has caused the issues.

We are done with all the components that are required; now run the test by clicking on the Start button on the toolbar. The toolbar offers handy buttons, such as Toggle Log Viewer for error logs and Clear all to remove previous results. Also, once the test starts, the tool will enable the Stop button to stop the test. Post the test execution, Aggregate Report should display the numbers we want to know.

During or after test execution, Aggregate Report will display the results. The table shows all the metrics that are required to create our baseline. The aggregated response at the bottom is either the sum or the average of different components. We should be looking at the metrics of each request, which will give us more relevant information.

The preceding figure shows the metrics values as follows:

If there are any errors reported, navigate to the View Results Tree component. It will show the error requests in red. Click on any of them to see the response received. If the test contains assertions, then expand the request tree to see the assertions that have failed.