nathandemick.com

Intro to load testing with JMeter

Recently for a project at work, I was tasked with doing research into load testing software. Now, there are tons of options for load testing; in my search I found some nice-looking hosted solutions, such as browsermob.com. But of course, if you can get away with doing something for free, that’s usually the option that makes the most business sense (that is, if the time you invest in learning the free tool is less than the money you would save by using the easier solution). The free solution in this case is JMeter, a Java-based program maintained by the Apache Foundation. Since I gained a basic understanding of the software through my recent research, I thought I’d share a bit here on how to create a basic load testing script. JMeter has many more options that what I’ll detail here, but hopefully this tutorial will at least get you over the initial learning curve.

Obviously, first of all you should download JMeter. Unzip the downloaded package, and place the whole folder structure somewhere easy to remember. If you want, you can set the /bin directory on your path so you can start the program from the command line. I just double-click the ApacheJMeter.jar package to start the program.

After JMeter starts up, you’ll be faced with a totally blank slate. What we want to do is create a group of users, and have each of those users perform a certain sequence of actions (such as access a URL, post a form, or whatever). There are two ways to do this with JMeter: enter the sequence by hand, or configure a proxy server to intercept your browser requests and save them as an action sequence. If the list of actions you want to perform is complex, it might be a good idea to set up a proxy. I’ll show you how to manually set up your test; running the proxy server will be reserved for a future post.

First, let’s rename the test plan to be something more descriptive. Click on the “Test Plan” text in the project sidebar, and rename it to something descriptive, such as “My Jawesome Test Plan.” Now, the first step in creating your test scenario is to make a group of users. Right click on your test plan, then select Add > Threads (Users) > Thread Group. “Thread Group” is kind of a confusing term, so you can rename the group to “Users” if you want. When you click on your user group in the sidebar, you’ll see there are various options you can change about it, the most significant being the number of users, how fast they start performing their tasks, and whether they repeat their tasks. Change the number of users to 10, and the ramp-up period to 10 as well. That means that it’ll take 10 seconds for all the users to be activated. Since there are 10 total users, that means that one will start up each second. Change the loop count to 2, so that each user runs through their tasks twice.

Next, we’ll add some configuration options to the test, so that you don’t have to enter certain info each time you want to add an action for the user group to perform (such as the base site URL). Right-click your user group and select Add > Config Element > HTTP Cache Manager. This simulates a browser cache for each of your users, so if they download a static resource on the first test run, they’ll have a cached version for the second, making the test more realistic. Select the user group again, right-click, and choose Add > Config Element > HTTP Request Defaults. You can put in any default options you want here, such as the site name, port number, and path. So for example, if you were testing your site foo.com, you could put in “http://foo.com” as the server name. Then all subsequent requests from your users would use that information. If a user requested plain ol’ “bar.html,” the defaults would be prepended to that request, resulting in a request to “foo.com/bar.html.” When creating a test by hand, the Request Defaults configuration becomes very useful. For our example, let’s query the JMeter site, so in the HTTP Request Defaults options, enter “http://jakarta.apache.org” as the server name.

OK, we’ve got the test users all set up. Next, let’s have them try to make some requests. Right click on your user group in the sidebar, and select Add > Sampler > HTTP Request. This represents a request for a single page or resource on your site. Let’s have it request the JMeter homepage. If you remember, we already set up the default site URL and path, so the only option we have to change for the sampler is the path value, which we’ll set to “/jmeter/index.html” (for the homepage). Also, change the name of the HTTP Request to “JMeter Homepage” so that it’s easier to see what it’s requesting.

At this point, you’ve got enough set up to actually run the test and see real results, but let’s go ahead and add another HTTP Request to the test. Right-click your user group, add another HTTP Request, and set the path to “/jmeter/usermanual/index.html.” Rename this request to “JMeter User Manual.” Now the test is completely set up, but there’s no way to view the test results yet. To remedy this, we’ll add two “listeners,” which track results and display them in a human-readable way. Right-click your user group, and select Add > Listener > Graph Results. Also Add > Listener > Summary Report. These are two simple listeners that show your results in a graph and text-based summary.

Now, go ahead and run the test by choosing Run > Start (or Command-R). Wait for a bit for the test to finish, then click on your results listeners. You should see the (hopefully successful) results of your test. Now for some embellishments. In a more realistic scenario, users would load a page, read it for a few seconds, then click a link to go to a different page. In the test script right now, your users make requests as fast as they can. To insert a random delay between requests, right click each HTTP Request in the sidebar, and choose Add > Timer > Uniform Random Timer. This timer allows you to set a base constant delay (such as 2 seconds), and then add another random delay on top of that. I like to have a 2 second constant delay and a 3 second random delay, so go ahead and edit both timers to have values of 3000 (random) and 2000 (constant). Also, ideally we want to make sure that the results of each request were successful. There are a number of ways to do this in JMeter, but the simplest is to make an assertion that each request returned a HTTP status code of 200. Right-click each of the HTTP Requests and choose Add > Assertions > Response Assertion. Modify each assertion to check the Response Headers, choose “Equals” for the Pattern Matching Rules, and add “200″ as a Pattern to Test. The Response Assertion is very powerful… you can modify it to check for patterns in the HTML of the requested page, etc., but this basic assertion is enough for our needs right now.

And that’s it! You now have a fully functional basic test plan. You can run it and see a cool graph of response times as well as get the summary report for the whole test. Hopefully that will get you started with the wonderful world of load testing.

2 comments · Written by Nathan at 8:00 am · apache, java, jmeter, nerd, web development