Home / Articles / Server Side

Load Testing with Apache JMeter | JMeter Installation

Created Jan 10, 2012
Tweet


JMeter Installation
JMeter version 1.8 needs JDK1.4 (the JMeter mailing list says that the latest development version, the "nightly build", also works on JDK1.3), and if JDK is on your computer, the
installation of JMeter is about the simplest youd ever experience. First download the JMeter zip file, then unzip it, locate the JMeter.bat file for Windows, or the JMeter file on Unix, and
run it. Some of the more advanced features in JMeter, like SSL handling, requires some further installation steps, and they are all described in the Users Manual.
When JMeter has started youll see this Swing client appear on your computer screen:

Building a Test Plan
Well now go through the steps of building a "test plan". As web server for all our examples well use Tomcat. The first example is the "Hello World" servlet application that is part of the
Tomcat distribution.
Step 1: Start JMeter

Run the JMeter.bat file for Windows or the JMeter file on Unix from the JMeter bin directory.
Step 2: Set the number of simulated users and the number of iterations

You do this by right clicking on the Test Plan node. Then select Add / Thread Group:

On the Thread Group you specify how many users you want to simulate, how fast theyre loaded and how many times you want to repeat the test plan. Well repeat the plan 10 times
for a single user:

Step 3: Describe the HTTP request (URL and parameters)

This is done by right clicking on the Thread Group node. Then select Add / Sampler / HTTP Request:

The address for the "Hello World" servlet ishttp://localhost:8080/examples/servlet/HelloWorldExample, and there are no parameters with the request:



Step 4: Select the format of the results

This is done by again right clicking on the Thread Group node. Then select Add / Listener / View Results Tree:

This will give us a page containing the results of every request:

Step 5: Run the test plan

You do this by selecting Run from the menu, and then Start (or Ctrl-R):

The test plan will now be repeated 10 times.
Step 6: View the results

When the run has completed the results can be seen in the Results Tree:

Here Ive selected the first request in the upper pane. Below you can see the request that was generated, and the results, which is an HTML page with the text "Hello World!" (only the
first part of the HTML is shown in the figure). We can also see the time it took to process the request: 110 milliseconds. Most of the other requests used less time than this.
Step 7: Add more listeners (optional)

One of the nice things about JMeter is its variety of listeners. If we want a tabular view of the requests we can add a View Results in Table listener. Heres what it would display after 10
new iterations:

If we only want a summary of the run we can add an Aggregate Report listener:

Heres how our test plan looks now with these two extra listeners added:

Step 8: Save the Test Plan

Dont forget to save your test plan for later use. Select File from the menu, and then Save Test Plan(or Ctrl-S). Actually you should save the test plan before you run it just in case
something runs wild.


Enhancing the Test Plan
You have now seen the basic elements used in a test plan. We added a sampler and some listeners, but as could be seen in the menus on the last page there are many other elements
that may be added to a test plan. The elements are logically placed in a set of groups:
Group Purpose
Samplers These are the elements that send requests to the servers. There are samplers for these request types:
HTTP/HTTPS, FTP, SOAP, JDBC, "Java"
Listeners They collect the results of your runs. You can select among graphical, tabular, single request views. The results can also be saved in a named file.
Timers Used to insert delays between the requests. They are needed to make your test more realistic.
Logic Controllers If the requests you have defined in your test plan should be executed depending on some logic, then you need the logic controllers. They are like the if-then-else
and loop structures in Java or any other programming language.
Configuration
Elements
They work with the samplers by adding common information about the requests.
Assertions Let you check if the responses you get contain the expected data or are received within a given amount of time.
Lets add a couple of new elements to the test plan from above.
When many HTTP requests are defined itd be nice if you could define the server name, port number, and common path only once. This is what the Configuration Element HTTP Request
Defaultsis used for:

For our example we add localhost and port 8080:

Now we can add another HTTP request, namely the "Date" jsp example thats part of Tomcat. It has the URL: http://localhost:8080/examples/jsp/dates/date.jsp. The procedure for
adding an HTTP request was explained above, so I wont show it again. You dont have to add "localhost" to the requestits already in the HTTP Request Defaults element. Due to a
bug in JMeter 1.8 youll have to add the port number 8080 though, even if it is given in the HTTP Request Defaults element. Give the two HTTP requests different names so they can be
distinguished. Your test plan now looks like this:



The order of the elements doesnt really matter, but its easy to rearrange them. Simply drag the elements to the proper position and answer "Insert Before", "Insert After", or "Add as
Child". Here Ive dragged "HTTP Req 2" up after "HTTP Req 1":

Now lets check if the response from the "Hello World" servlet really contains the text "Hello World". First we add a Response Assertion element to HTTP Req 1:

Then we state that we want to look for the text "Hello World!":

If the check fails, then the HTTP request will be marked "in error", just as if an HTTP error like "404" was received. To see the results of the assertion we add to the Thread Group a
Listener forAssertion Results (in the same way as the other listeners).
Finally, well now add a Timer element to get a more realistic test scenario. We select a Uniform Random Timer, where the timer delay for each request is defined as a fixed part plus a
variable part:

We set the minimum delay to 2 seconds, and the variable part to 1 second. This will simulate a user that sits and thinks between 2 and 3 seconds before giving the next request.

Before we start the run, we define 20 threads (users) starting within 10 seconds (2 per second), and repeating the two HTTP requests 100 times. The test plan looks like this:

In case something gets out of control its always a good idea to save the test plan before you try to run. Select Aggregate Report so youre ready to view the results, and then press
Ctrl-R to run.
On my Win98, 866MHz computer with 128MB RAM, I get these figures:

Response times are in milliseconds. The last column is the number of requests per second (e. g. "HTTP Req 1", 20 users, average response time 0.1 sec = 200 requests per second).
Note that the number of errors is 0%. This means that the assertion reported OK.
Dont expect to be able to simulate much more than 20-30 users on a computer such as I used. Im running JMeter on the same computer as the web server, and thread handling in
JMeter takes many resources, as we will see shortly.


Recording a Use Case
One of the really useful features in JMeter is its ability to record what you do in your browser. If you want to make a test plan for a use case, where a user working with her browser
goes through a series of screens, entering data, clicking on buttons and hyperlinks, then its quite a job to create the JMeter HTTP Request elements by hand. The HTTP Proxy Server is
the solution to this task. The idea of a Proxy is to sit between your browser and the web server:

You must define this setup both in the browser and in JMeter. First you let the browser direct its requests to some port number, say 8090. In Internet Explorer v.5.5 you select Tools /
Internet Options / Connections and then press either the LAN Settings or Settings button. Then you select a proxy server named localhost using port 8090:

Be careful with this setup. If recording doesnt work then its probably because your proxy settings arent quite correct.
In JMeter first remove all HTTP Request elements from your test plan. Keep only the report elements you want to use later on for viewing the results. The setup could look like this:

Then you let JMeter listen to the port number entered in your browser. You do this by adding theHTTP Proxy Server element to the WorkBench node:

Then you set the port number, and press the Start button at the bottom:



Now were ready to go. First well record a scenario from the article
"Coding your second Jakarta Struts Application". If youre interested in
using this application yourself youll find a link in the resources section of
that article where you may download the application (as a war-file ready
to install in Tomcat).
Well execute these actions in the browser:
list all DVDs
select the second DVD
create a new DVD
go back to the list with "Cancel"
select the new DVD
delete it
select the third DVD
update it
go back to the list with "Cancel"
Save the list of DVDs
The DVD application is started by the
address http://localhost:8080/dvdapp/list.do. If you size JMeter and your
browser making both visible, then its easy to see when an HTTP request
is added in JMeter. Heres the first request added:

When the whole use case has been completed, you can see every request
in JMeters left pane:

By selecting one of the requestsfor example, the "DVD update" action,
you can see the parameters sent from the browser to the server. This
could be useful when debugging an application!

Having recorded the use case, we may run it but first we must consider
one thing, A servlet application like this uses a Session object, which
typically is maintained by sending a cookie between the browser and the
server. JMeter makes it very easy to accomplish this, just add anHTTP
Cookie Manager to the Thread Group:

When I tried to run this use case with the same number of threads and
same loop count JMeter threw several OutOfMemoryErrors. In the JMeter
newsgroup you can read about what may be done to avoid these errors,
but again, if you want to simulate a large number of users youll need a
large computer for running the JMeter server (see next section about
remote testing), and maybe also another platform (Windows XP
Professional or Solaris).
To simply get the response times I defined one thread, and looped 100
times:

Some of the actions (create, update, delete and cancel) use the same
URL so Ive given each request a unique title, seen in the URL column.


Measuring Web Services Response Times
The next application to test is from the article "Using Apache Axis version
1 to build Web Services". Its currently not possible to record a web
service (SOAP) application automatically so well have to enter each web
service request by hand. Well also have to download the latest nightly
build of JMeter, since the SOAP support was not fully implemented in
version 1.8.
Setting up a SOAP test plan resembles what we have seen above for
HTTP test plans. To theThread Group we first add a SOAP sampler:

In the sampler we must set the complete URL of the SOAP request. We
must also set the SOAP data, and this isnt always easy, because it has a
complicated format. I find the simplest way to do this is to start
Axis SoapMonitor, run the client, copy the SOAP data from
the SoapMonitor, and paste it into the JMeter SOAP request. A request
looks like this (this is a request for getting the DVD titles):

Then we must also add an HTTP Cookie Manager (same reason as
before), and an HTTP Header Manager to set the SOAPACTION header to
blank.
If we run this SOAP request once, we get this result in View Results
Tree Listener:

You can spot the titles of the 3 DVDs at the bottom of the SOAP
response.
Entering all the SOAP requests for the full DVD use case is fairly
straightforward, but boring. Heres the complete setup seen in the left
pane:

To see what the response times are for single requests we define only
one thread and loop 100 times:

If you compare the numbers with the numbers in the corresponding table
for the web application, youll see that the SOAP application uses
somewhat more resources. This shouldnt be a big surprise, since Axis
has some unpacking and packing of XML data to work with.
The Third Application
The final application that well test is a mixture of the two others, its a
browser application using Struts to invoke the DVD web service system
we have just tested. The response times will therefore be higher than
times from the first two applications. Again well test with a single thread
and well loop 100 times. The results are these:

Not a big surprise. The numbers are somewhat higher than the web
service application. The test setup is a bit artificial. Theres only one user,
so the numbers are the best (lowest) that can be expected. But what
happens if we put 30, 50 or 100 users on the applications? Lets finish by
looking a bit into this rather complex area.
Remote testing
If you want to get realistic numbers for a load test then its important
that the computer where JMeter runs has enough power to handle
sending requests and receiving responses at the speed youve specified.
You shouldnt therefore run JMeter on the same computer as the web
server, as weve been doing in this article. Even when JMeter is running
on its own computer, there might not be sufficient resources. A good
indicator of whether or not the JMeter computer is powerful enough is to
watch its cpu usage. If it goes near 100% then you will probably not get
accurate results.
One thing thatll slow JMeter down is if you have many listeners active.
Use only a simple listener like the Aggregate Report listener or write the
responses to a file. All of the listeners have a field where you may enter
the name of a file to record to. Later, when you want to see the results
from your recording file, you simply enter its name in any of the listeners
"file field" and youll get a report shown. This is a nice feature.
JMeter also has a "Batch" mode, or GUI-less mode, where you must give
the name of a file containing a test plan and the name of a file to store
the results. The format of the command is this:
jmeter n t<name_of_test_plan_file> -l<name_of_log_file>
If you dont want to work without the GUI, you may run JMeter in "Server
mode". This is a setup where JMeter is run on two computers. One runs
the GUI and the otherthe JMeter serverruns the communication to the
web server (and to the JMeter client).

Heres how you setup this configuration (see also JMeters User Manual,
chapter 10).
On the JMeter Server computer you must first start the "RMI Registry
application" thats part of the JDK. Youll have to put these three jars in
the CLASSPATH first:
JMETER_HOME/lib/ext/ApacheJMeter_core.jar
JMETER_HOME/lib/jorphan.jar
JMETER_HOME/lib/logkit-1.0.1.jar
Now locate and run the rmiregistry application in the JDK bin directory.
No parameters are needed.
Then start JMeter on the same computer:
jmeter s
The "s" indicates that it runs as a server.
On the JMeter client computer you must first enter the IP address of
the JMeter Server into thejmeter.properties file found in the bin directory.
Locate these lines:
# Remote Hosts - comma delimited
remote_hosts=127.0.0.1
Insert the IP number of the JMeter Server instead of 127.0.0.1. You may
now start JMeter in the normal GUI mode. You enter your test plan just
like youre used to, but when youre ready to run, you select Remote
Start from the menu:

Again, you should observe the load on the JMeter Server to see that its
not the bottleneck in your setup.
I havent tried it myself, but the Users Manual mentions that you may
run more than one JMeter server from the same JMeter client. This would
surely help putting a high load on your web server.
Conclusion
JMeter is an excellent tool for performing load testing, mainly because its
so easy to use. You must however be prepared for minor bugs, and also
allot enough use time for setting up a proper test environment if you
need accurate results for critical applications.
Resources
Home of JMeter at jakarta.apache.org
JMeter Users Manual
The JMeter Newsgroup lots of questions and answers
Some of my previous articles from JavaBoutique about Axis and Struts:
- "Web Services with Axis"
- "Coding your second Jakarta Struts Application"
- "Using Apache Axis version 1 to build Web Services"
- "Digging deeper into Apache Axis"

Keld is currently working as a web architect for one of the largest IT
companies in Denmark. He battled with the mainframes during the 70's
when they were the size of a gymnasium and had the power of your
PalmPilot. He also struggled with CASE-tools in the 90s and now explores
the cutting edge technology of the Web. While not busy at his computer
he likes to vacation on the Greek islands.