JMeter RealTime Scenario..

How would you go about writing a JMeter based performance test case for the following scenario?

XML/HTTP based RESTful Web Service calls are made against an order execution system. The system should be able to handle a basic load of 30 orders per 3 min. There will be 30 concurrent users. This means 600 orders per minute.
The test case should simulate at least 2 different account ids.
30 orders per 3 min x 60 minutes = 600 orders per hour.

A. The JMeter version 2.4 is used for the following screenshots. The number of artefacts shown for this are as shown below.

STEP 1: Relevant files.

OrderExecution.jmx is the JMeter script.
1-OrderRequest.xml and 2-OrderRequest.xml are the two sample XML payloads that will be sent via an HTTP POST (RESTful Web service).
TestData.csv is a data file used for retrieving values 1 & 2 to switch between 1-OrderRequest.xml and 2-OrderRequest.xml to simulate 2 different accounts.


//?xml version="1.0" encoding="UTF-8"?>



//?xml version="1.0" encoding="UTF-8"?>



STEP 2: JMeter scripts
If you open the OrderExecution.jmx script file, you will see something like this.

Lets' go through each of the elements. Thread Groups are equivalent of virtual users in other performance testing system. You can add this element by right clicking on the test plan and then selecting Add --> Threads (Users) --> Thread Group. As per the requirements, the system should handle 30 concurrent users. The ramp up time is 180 seconds, which is 3 minutes. All 30 threads will get started in 3 minutes. The loop count is set to 20, to produce 600 orders (i.e. 30 threads * 20 loops) .

It is a good practice to define some variables as shown below, so that these variables can be used in downstream elements without having to hard code. If you want to run against a different host, you can just change it in spot as opposed to having to change it in a number of places. You can add this by right clicking on "Order Processing" and then selecting Add --> Config Element --> User Defined Variables.

The CSV Data Config is a very useful element to read test data from CSV file and then save the read values into some variable. In this example, the values 1 and 2 are read from the file TestData.csv, and stored in a variable named "account". The one iteration will set account to 1, and the next iteration will set it to 2, and then the same assigment repeats since "recycle on EOF" is set to true.

The HTTP Header manager sets the HTTP headers. In this example, the content type is set to application/xml because we are posting the XML files 1-OrderRequest.xml & 2-OrderRequest.xml .

The HTTP request defaults sets the default values so that you don't have to repeat it in each request. Also, note that the user defined variables in the first step are used within ${} as opposed to literal values.

The loop controller can be added to loop through the samplers a number of times. In this example, it is set to 1.

The samplers can be added by right clicking on the "Create Order" loop controller and then selecting Add --> Sampler --> HTTP Request. It shows the path, method, and the file to send. The actual RESTFul web service call will have the URL

Also, note that in the File Path the ${DATA_PATH} is a user defined value, and ${account} is a variable that is assigned from the TestData.csv file via the CSV Data Config element. The account will be dynamically changed between 1 and 2 to retrieve the files 1-OrderRequest.xml and 2-OrderRequest.xml respectively for each iteration.

JMeter supports a number of samplers like SOAP request, FTP request, JDBC request, JMS publisher, JMS subscriber, etc to name a few.

The XPath assertions are used to assert the response for presence of responseCode="SUCCESS" and a valid orderId > 0. The response message will look like

//xml version="1.0" encoding="UTF-8" standalone="yes"?>

The other three elements are reporting elements. There are many reporting elements to choose from depending on the requirements. You can add reporting elements via Add --> Listener.

Finally the Gaussian Timer that will delay the execution by 3 minutes (i.e. 180000 ms) with a standard deviation of 10 seconds. This will ensure the throuput of 30 orders per 3 minutes.

No comments: