COMP9321 Exercise: Performance Testing

Lab08 Mark and Deadline

This lab is based on lectures given in Week 11 on Performance Measurement. We will use PSI probe and Jmeter to measure the performance of the Movie Characters (JDBCDAO) application from the database lab. Here is the war file if you do not have the application at hand. However, you still have to set up the Derby database beforehand

1. Deploying Probe

First download the PSI probe war file.
Using command line, start your Tomcat server
```
$ bin/catalina.sh start
```
Via browser, go to http://localhost:8080 and click on 'Tomcat Manager'. The default admin username and password is 'tomcat' and 'tomcat' unless you have changed them (see tomcat-users.xml in your tomcat conf/ directory).
Once you have logged in, go down to 'Deploy' section and in the subsection 'WAR file to deploy', browse to the 'probe.war' file that you downloaded earlier and click on 'Deploy' button. Tomcat should give you an 'OK' message.
You can see the PSI probe application in the list of applications. Clicking on it will give you a webpage with details of applications in your Tomcat container.
If JDBCDAO is not already present in the list of applications in your Tomcat container, start Eclipse and export the application as a WAR file. Using the same mechanism from Tomcat manager page, deploy the WAR file as well.
You should be able to see both the JDBCDAO and PSI probe applications now in the list of applications in the Tomcat Manager. Click on the probe application or go to http://localhost:8080/probe to load the PSI probe page.This should give you a page like this:
The PSI probe prage should list all the applications running in your container and various details about them. One of the links is your JDBCDAO application. Clicking on that link should give you a page like this:

2. Deploying JMeter

Download and unpack JMeter
Start JMeter
```
$ bin/jmeter.sh 
```

For this lab, test JDBCDAO with different numbers of users in one minute, starting from 10 up to 50 with an interval of 10 (i.e. 10, 20, 30,.. 50). For each set of users, record the median response time on the client side (i.e. from JMeter). Show the output to your tutor. If your application crashes beyond a particular set of users, record that as the maximum number of users you can handle simultaneously. See below on how to conduct the test.

Testing the web application

What we have done so far is to set up a framework for analysing performance of a web application. There are two parts to performance of web applications: the response seen by the client to his/her inputs, and the load generated on the server for executing the client's actions. In the framework set up, JMeter is used for measuring the client-side performance and PSI Probe for the server-side performance. Below are the steps to conduct a performance test using the JDBCDAO application as an example

How to test performance ?

First, we need to decide what we want to test. The JDBCDAO application has the following steps:

Click on a character and either 'Character Info' or 'Comments'
List details of a character if Character Info is selected.
List the comments if Comments is selected.
Post a comment.

We will test these operations individually.

We start from where we left off in the lab with JMeter started and PSI probe monitoring the Tomcat server. First, we need to simulate a number of users. In JMeter, right click on 'Test Plan' in the left panel and add 'Thread Group'. Here, we have added 5 users with a ramp-up period of 60 secs. (i.e. the number of users will increase from 0 to 5 in 10 secs)
Now we put in the details of the application that we want to test. All operations are directed by the ControllerServlet which is reached at '/JDBCDAO/controller'. Rather than having to type this for each operation, we add a HTTPRequest configuration element ('Config Element --> HTTPRequest Defaults') to the Thread Group.
Now the user has to select a character and an option on the front page to access the functionality of listing character details. These are passed to the server as parameters in the HTTP request. We first add a Simple Controller (Add -> Logic Controller) to drive this operation. To this, we add a HTTP Request Sampler (Add -> Sampler -> HTTP Request) and configure like so:

Then we add the request parameters in the "Parameters" tab, like so:
Now, to test posting of comments. After we access the character details, a link on the page leads to a comment form. The comment post is a POST method. So we add a new HTTP Request Sampler appropriately, like so:
Now, we need to examine the results of our testing. First, we need to see if the successful responses are actually showing success of operations. In this web application, a failure results in a page containing the word FAILED. If this word is not present, we can consider the operation to be a success. I have done this using a Response Assertion (Add -> Assertion -> Response Assertion). If the operation is successful, this assertion returns true.

(Guess what happens when I put a comment with the word FAILED in it ?:))
Now, we need to visualize the results of our test. This is done by Listeners. We will add a 'View Result Tree' Listener and write the aggregate results to files using a 'Aggregate Report' Listener.
Now, to run our test. Click on 'Run' and then 'Start'. We have started with 5 users in 60 secs. So, wait until the test ends (the small square in right upper corner turns grey). Then, click on View Result Tree and individual request response pairs. You will get something like this

And the aggregate report would look like this. Save the aggregate report to another file. This will be useful for statistical analysis:
Now, load the probe page to check the server load for that test. You should see something like this

You can click on the data source, servlet, session,etc. to get an idea of the server resources used for running your tests.
That's it, done! Explore more of JMeter's and PSI Probe's features for customizing your tests.

P.S.: If you have not been able to run the test successfully, you can load this test plan.

Notes on logins

Many times, the user has to login to gain access to other operations. But this operation has to be performed only once. So we can use a 'Once Only Controller' to drive this operation. To the Thread Group, add 'Logic Controller --> Once Only Controller'. Now, the actual login request is a HTTP POST operation activated the user clicks on 'Login' button after filling in the form with username and password. So, add the appropriate HTTP Request Sampler to this controller.

The login is done only once but then the user session is used to authenticate and keep track of the user operations thereafter. So, we need to keep the session alive throughout the test by retaining the cookies. So, we need to add a Cookie Manager to the Thread Group (Add -> Config Element -> HTTP Cookie Manager)