JMeter is a tool for load-testing and measuring the performance of Web sites and Java applications. It supports servers that accept HTTP and FTP connections but can be used to test databases, Perl scripts, and Java objects as well. JMeter supports basic script recording via a proxy server and requires a thorough understanding of the underlying protocol and server implementation. Creating a test plan demands manual work, but just like JUnit, it is the kind of challenging work that developers actually enjoy. Because most of the new applications built today have a thin client interface, we will use JMeter to load test a Web-based product called WebCream.

JMeter has a GUI that can be used to create a test plan and an engine that executes the test plan to generate the load. The test plan is a container for the configuration elements and logical controllers that represent settings and actions to be performed. The test creation is visual, and the end result is a tree of nested elements that describes the test and its execution. Using HTTP Proxy Server, which records the browsing actions, is a good way to quickly create a draft test plan. Whether you start by recording the test plan or by creating it manually, you need to know the elements used by JMeter to make the test plan work. The following nodes can be added to a test plan:

A thread group can have these additional nodes:

After a test plan is created, it can be executed on the local machine. You can also configure several machines to act as remote JMeter servers, which can be controlled from the same GUI environment. This allows simulating more virtual clients than one machine can handle.

WebCream is a unique tool for Java that provides automated Web enabling for GUI-based Java applications and applets. WebCream allows developers to implement a GUI front end using AWT and Swing and, at the same time, automatically get HTML access to the application. In a way, WebCream can be thought of as a dynamic Java-to-HTML converter that transforms GUI frames and dialog boxes to HTML on-the-fly. It then emulates Web page actions as GUI events to retain the application's original logic. WebCream is unique in that it requires no modifications to existing forms or business logic and does not require programmers to learn any APIs. Because WebCream uses a browser-based interface, generates dynamic content, and maintains a session, it is a good choice for HTTP load-testing with JMeter.

WebCream comes with a built-in Tomcat Web server and a demo application; you should play with it a little bit to become familiar with the product. Use the WebCream demo application and be sure to check the HTML source the product generates for each page. Try to understand the URLs used by the product and how it passes the data back to the server, and look for common patterns in generated pages. The standard edition of WebCream is free but limited to five concurrent users, so you might have to restart Tomcat during your tests if you don't want to wait for the sessions to time out. The WebCream demo's main page displays a frame with three buttons—Login Dialog, Tabs and Table, and Tree Dialog (see Figure 11.2).

Figure 11.2. The main HTML page of the WebCream demo application.

Clicking the Login Dialog button displays the next page, which shows a dialog box allowing the user to enter her username and password and to select a domain. If the OK button is clicked on this page, the login information is passed to the main page. For the purposes of testing, we will limit ourselves to this functionality of the demo.

Now is the time to actually do some work. Download and install JMeter and WebCream. Run the JMeter GUI using the JMeterinjmeter.bat file. Because we are going to be testing WebCream, start the built-in Tomcat using WebCreaminstartServer.bat.

The initial tree in the JMeter GUI shows an empty test plan and a WorkBench. The WorkBench is just a placeholder for the temporary nodes and testing, so we will focus on the test plan. Because we want to simulate multiple simultaneous users, we must add a thread group by right-clicking the Test Plan node and selecting Add, Thread Group. Initially, we set the number of threads to 1 to simplify the testing, but later we will change it to 5. To simulate real-life user interactions with the server, we need to ensure that the user makes pauses before sending the requests to the server. One hundred concurrent users in real life does not mean one hundred simultaneous requests on the server because users spend time interpreting the server response and filling out data on forms (sometimes even taking a coffee break). JMeter provides the Gaussian Random Timer for the simulation of user delays. We add it to our thread group and specify a constant delay of 300 milliseconds with 100 milliseconds deviation. This means that JMeter will pause a thread for at least 300 milliseconds before trying to execute the next step of the test plan.

Before we embark on devising the HTTP requests to simulate, we need to take a few preparatory steps. WebCream maintains an HTTP session, which relies on cookies stored in the browser. We are simulating a browser-based client, so we add HTTP Cookie Manager to the thread group. Just adding this configuration element is enough to tell JMeter to store cookies, and we don't have to define any cookies manually.

Last, but not least, we want to use the HTTP Request Defaults configuration element. It is a convenient way to provide the common information in all HTTP requests only once. Obvious choices for inclusion into the HTTP Request Defaults are the protocol (HTTP), server name (localhost), path (/webcream/apps/WebCreamDemo), and port number (8040). If you looked carefully at the source of WebCream-generated HTML pages, you would notice that three hidden parameters are present on every page, as shown in Listing 11.3.

<input type="hidden" name="__RequestId" value="1">
<input type="hidden" name="__WindowTitle" value="WebCream Demo">
<input type="hidden" name="__Action" value="">

As the user goes through the pages, the values of these parameters change to reflect the consecutive request number and the current window title. The __Action parameter is used to tell the server which action to perform on the application. For example, to close a window, the client code sets __Action to close. Because these parameters are sent with every request, it is prudent to include them in the HTTP Request Defaults. We use the JMeter GUI to add the three parameters, leaving the values blank for now. We will return to specify the values after you learn a little more about JMeter. Figure 11.3 shows the plan tree we have created so far.

Figure 11.3. The JMeter test plan tree, step 1.

We will simulate a user opening the WebCream demo in a browser, clicking Login Button to go to the Login page, and then clicking OK to go back to the main page. To ensure that there are no memory leaks or multithreading problems on the server, we will simulate the user opening and closing the dialog box several times.

To keep the test plan concise, we add Once Only Controller to the thread group, enabling us to group the sampling requests into a subtree and separate them from the configuration elements. Next, we add HTTP Request Sampler to the controller. We name it HTTP Request - Init and, because it is the initial request to the Web application, we specify the GET method and leave everything else blank. The information about the Web server (such as the protocol and host) is coming from the request defaults we specified earlier. At this point, we have created a step that is equivalent to a user typing

http://localhost:8040/webcream/apps/WebCreamDemo

in the browser address bar and pressing Enter. The server should respond with the main page (refer to Figure 11.2). We should verify that we got the right response; we do so by adding a Response Assertion to the HTTP Request - Init node. An assertion can be as simple as a substring that must be present in the response or as sophisticated as a number of regular expressions that should produce a match. We will keep it simple and just test that the response is the page titled WebCream Demo as we have seen in the browser. While writing the test plan, it helps to keep the browser open with the page you are scripting against. To complete the assertion, we specify that we want the response to contain the pattern <title>WebCream Demo</title>. Figure 11.4 shows the plan tree we have created so far.

Figure 11.4. The JMeter test plan tree, step 2.

We are now ready to proceed to the test that opens and closes a page with a dialog box. We want to do it several times, so we first add a Loop Controller logic controller to the Once Only Controller and specify 5 as the loop count. Our next task is to add an HTTP Request Sampler that simulates the user clicking the Login Dialog button. To see what has to be sent in this request, we need to open the source code for the main HTML page. Searching for Login Dialog takes us to the code shown in Listing 11.4.

<form name="WebCreamForm" method="POST"
      action="http://localhost:8040/webcream/apps/WebCreamDemo"
      onSubmit="onSubmitForm()"
>
...
    <input type=button
       name="JButton31266642"
       value="Login Dialog"
       class=button
       OnClick=javascript:doSubmit('/button/JButton31266642')
       style="position:absolute;left:84;top:5;width:103;height:26"
    >
...
</form>

With some HTML familiarity, you can determine that when a user clicks the button, it invokes the doSubmit Java script passing '/button/JButton31266642' as a parameter. Searching for doSubmit on the page and the included JavaScript files produces the following snippet found in webcream_misc.js:

function doSubmit(action) {
  window.document.WebCreamForm.__Action.value=action;
  onSubmitForm();
  window.document.WebCreamForm.submit();
}

Thus, we conclude that when a user clicks the Login Dialog button, it sets the __Action parameter to /button/JButton31266642 and submits the form to the server. Accessing the WebCream demo using the browser several times, we can see that the action string is changing. It always starts with /button/JButton, but the remaining numbers vary from time to time because they are automatically generated. Most Web pages have some form of dynamic content, so the technique we use for WebCream is useful for other applications as well.

To work with dynamically generated content in JMeter, you must rely on variables and regular expressions. The Regular Expression Extractor is a postprocessor that applies a regular expression to the sampling response and places the extracted value into a variable. Regular expressions are a powerful mechanism of working with text input; if you are not familiar with them, I recommend learning about them. There is a plethora of references and tutorials covering regular expressions on the Web, and even a book from O'Reilly called Mastering Regular Expressions.

After a variable is initialized by the extractor, its value can be passed to other test elements such as samplers. We will use the extractor to obtain the values for the three parameters we have defined in HTTP Request Defaults (__RequestId, __WindowTitle, and __Action). We right-click the Http Request - Init node and add a post processor called Regular Expression Extractor. Next, we append - Request Id to the name of the extractor because it will be used to retrieve the value of this parameter. In the configuration screen for the extractor, we specify __RequestId as the reference name. Doing so tells JMeter that the result of the extraction should be stored in a variable called __RequestId. Looking at the HTML code in Listing 11.3 that defines the hidden form parameters, we can come up with a regular expression that will match the value of the __RequestId:

name="__RequestId" value="(d+)"

This regular expression uses static characters to uniquely identify the __RequestId definition and d+ mask to specify any number of digits. The parentheses specify which part of the expression should be used as the result. Because we are interested only in the numeric value, the parentheses surround d+.

The template in the extractor enables the creation of a string out of the matches found by applying the regular expression. The template can include static text and $n$ as a placeholder for the nth match of the regular expression. We are expecting only one match, so we specify $1$ as the template—and we're done with the __RequestId extraction.

Similarly to __RequestId, we should add two more extractors for the __WindowTitle and __Action variables. This is a good time to exercise your brain and come up with your own regular expressions and template strings. But just in case, I'll make your life easier by saying that the regular expression for __WindowTitle can be

name="__WindowTitle" value="(.+)"

and the template can be $1$. The __Action regular expression can be

name="(JButtond+)" value="Login Dialog"

and the template should be /button/$1$. The key in coming up with the regular expression and template is to produce a string that can be used as a value of a parameter for the next request. Figure 11.5 shows the test plan tree we have created so far.

Figure 11.5. The JMeter test plan tree, step 3.

We are not ready to use the variables, which contain the extracted values, as parameters to HTTP requests. We have already defined the parameters in the HTTP Request Defaults node, so let's go back to it and specify the values. To obtain a value of a JMeter variable, we must the use the syntax ${name}, where name is the name of the variable. We specify ${__RequestId} as the value for the __RequestId parameter, ${__WindowTitle} as the value for __WindowTitle, and ${__Action} as the value for __Action.

Hang on, we're almost there. Before running the test, we need to add a few listeners to monitor the test execution. To test the script, the most useful listeners are View Results Tree and Assertion Results. View Results Tree shows each request with the request and response data, whereas Assertion Results is a quick and easy way to see which assertions have failed. You should not keep View Results Tree in the final version of the test script due to the performance overhead associated with collecting and storing all the data. Finally, we add the Aggregate Report listener to produce a summary of the execution and performance metrics per request.

If you have followed all the steps correctly, your test plan should look as shown in Figure 11.6.

Figure 11.6. The JMeter test plan tree for WebCream, finished.

Make sure that WebCream's Tomcat is running, and unleash the fury of JMeter by selecting Start from the Run menu. After a few minutes, the test should finish and you should be able to see the results in the listener nodes.