Introduction

Apache JMeter is a program that can test the performance of various servers. It natively supports the following protocols:

• HTTP(S)
• LDAP
• JMS
• SOAP
• JDBC (needs appropriate JDBC driver)
• SMTP(S)
• POP3(S)
• IMAP(S)

Besides those, JMeter also has a lot of plug-ins that can be used to test the performance of other services implementing other protocols not described above. Most of them (but not all) can be found on the jmeter-plugins web site. After downloading and installing the jmeter-plugins package, new entries will appear in the graphical user interface menu in JMeter.

After downloading the JMeterPlugins, we need to extract it:

# mv JMeterPlugins-0.5.3.zip JMeterPlugins/
# cd JMeterPlugins
# unzip JMeterPlugins-0.5.3.zip
# cp JMeterPlugins.jar ../apache-jmeter-2.7/lib/ext/

After that we just need to restart the JMeter and the jmeter-plugins should be loaded just fine. This works because JMeter automatically searches for classes in the /lib and /lib/ext directories. The /lib directory contains utility jars, whereas the /lib/ext directory contains JMeter components and add-ons.

When we start JMeter, its user interface will look like the picture below:

Test Plan

A test plan in JMeter specifies the steps the JMeter will test when it is run. There are various elements that can be added into the test plan, each of which is responsible for certain aspects of the test process. When the JMeter is loaded it can't do anything by default, because there are no test elements added to the test plan; the test plan is empty. To add appropriate elements we must first know what we would like to test. If we'll test a HTTP server we must add different elements than if we're going to test a LDAP server. But some of the elements are mandatory and must be used regardless of the testing server. Those elements are the following:

• Thread Group
• Logic Controller
• Listener
• Timer
• Assertion

To add elements to a Test Plan we must right-click on the "Test Plan" and choose "Add" for a menu of elements to become available. There are a number of element groups, which we'll describe later.

The first thing we should do when defining a Test Plan is to save it to some file, so we don't lose the already configured options later. To do that, we must click on Menu – File – Save Test Plan as and save it. This is shown in the picture below:

Alternatively we could do the same thing by right-clicking on the "Test Plan" and selecting "Save Selection As" and save the Test Plan. Here we must also mention that we don't necessarily have to save a whole Test Plan, but can also save a subset of a test plan, which can prove useful if we only want to save a specific element we would like to later import into all test plans.

To run the test plan, we could click the Menu – Run – Start or a green play icon in the toolbar menu; those two are equivalent.

Notice the green play icon in the above picture; it's a Start button. On the right side of the picture there are some numbers and a little square. The square notifies us whether the JMeter is running or not. In the above picture we can see that the square isn't colored, which indicates that the JMeter was not running at the time the picture was taken. If the square had been green, it would mean that the JMeter is running.

The numbers to the left of the square are the number of active and the number of total number of threads.

Let's now look at the Test Plan options that we can configure. They are shown in the picture below:

Okey, first we can name our test plan, which by default is simply "Test Plan". We can also provide a description of our test plan, but this isn't required. After that there is a little space for user defined variables, which can be used to replace a variable with some static string when the test is being run. Those variables can be used in any test plan element, except for the test plan itself. An example of defining a variable is the IP address of the HTTP server being tested. We can assign an IP address a certain variable name, which can then be used in all the test elements. When we would like to test another server, we would only have to change the IP of that variable and not all the values of the test elements which use the IP address for testing.

If we would like to test the Google DNS server, we could define the variable name host as shown in the picture below:

Then we would need to reference the IP address of the Google DNS server by using a host variable and not by using the IP address directly.

There are also other options in the Test Plan. "Run Thread Groups Consecutively" runs groups one at a time and not in parallel. The "Functional Test Mode" saves the data returned from the server for each request in a file as defined in a test listener. This should only be used when testing our configuration options to ensure that JMeter is functioning properly. We shouldn't enable that option when stress testing because each response will be saved into the file on disk, which decreases the performance of JMeter considerably. We defined a test plan for InfoSec Institute where only one request would be sent with the "Functional Test Mode" turned to on, just to see what will be written into the filename that should store the responses of requests. After running the test plan, the filename looks like the output below:

 <?xml version="1.0" encoding="UTF-8"?>
<testResults version="1.2">
<httpSample t="960" lt="369" ts="1346340056672" s="true" lb="HTTP Request" rc="200" rm="OK" tn="Thread Group 1-1" dt="text" by="35425">
  <responseData class="java.lang.String">[RESPONSE]</responseData>
  <cookies class="java.lang.String"></cookies>
  <method class="java.lang.String">GET</method>
  <queryString class="java.lang.String"></queryString>
</httpSample>
</testResults>

I didn't provide the response of the above request into the printed output for clarity, but I've marked where the response should be with [RESPONSE]. The [RESPONSE] should simply contain the HTML code of the default InfoSec Institute web page. We can see that the "Functional Test Mode" functionality works and does what it promises, but if the option would be enabled when stress testing, the JMeter's performance would be degraded.

Lastly we can also add our own directory to a classpath, which means that if we write a plug-in for JMeter we don't need to copy it to the /lib/ext directory in the JMeter home directory, but we can select the directory of our choosing and JMeter will recognize it and load the plug-in correctly.

Conclusion

In the next part we'll take a look at the JMeter elements and describe them in detail. We'll also describe the execution order and scope of the JMeter elements.