Making Load Testing Graphs With JMeter Using PowerShell



Last updated: January 28th, 2024

Required Installations

To run JMeter you will first need to download and install Java. After you have it, you will need to download JMeter. Additionally, to report back the results of your JMeter test plans in a command-line driven fashion, you will need to get a module called JMeterPluginsCMD and place the .jar in the lib\ext directory where you have JMeter.

If you want to run this on Windows through the command line, it’s best to use PowerShell. One reason to use this with PowerShell is to leverage the psake module which is useful for setting dependent and downstream tasks. It will enable a task to run that does the load testing then have another task to generate the report output.

Building a Plan

To use JMeter, you will need to make a test plan that is essentially an XML file interpreted by JMeter, ending in the extension (.jmx). Unlike a standalone application, JMeter must be launched through the command-line using Java. The best way to do this is to CD into the directory for Java, assuming the default paths, that is: "C:\Program Files (x86)\Java\jre7\bin". Once in that directory, pass an argument to it for your JMeter path, for example: "C:\tools\apache-jmeter-2.9\bin\jmeter". If you want, you can make this a psake task (as in down below).

After launching the JMeter UI, you are presented with the application where you can build a plan. JMeter should default to a blank test plan, you should give it a meaningful name. Next, right click on the test plan and go to: Add > Threads > Thread Group.

In this case, we are going to make a simple thread group that represents getting a page 10,000 times that will report back to us the average response time in milliseconds. Each of 10 users (or threads) will concurrently make a request, waiting for a response before the next request they make, this will happen 1,000 times for each user, 10,000 requests in total. The response time for each request will be logged to a result file, a .jtl file that the command-line plugin will pick up and generate results from.

To set up the plan, set the Number of Thread (users): to 100, the Ramp-Up Period (in seconds): to 0 and the Loop Count: to 1000. From here, save the file with a meaningful name like: load_test.jmx. Right click on the thread group you’ve made and go to: Add > Config Element > HTTP Request Defaults. From here, popular the Server Name or IP with the domain name you want to hit, if it’s HTTP then use Port Number: 80 else if it’s HTTPS use 443. Set the protocol accordingly. This will make future requests easier to manage. Next right click the thread group and go to: Add > Sampler > HTTP Request. This is where you configure the Path (relative location such as: /mypage.html), the Method (GET in this case) and any other parameters you want to add for the body. If you need to add HTTP headers, you can configure that with the HTTP Header Manger.

From here you will want to add a way to report the request results. That can be done with the Spline Visualizer, right click the thread group then: Add > Listener > Spline Visualizer. To save the results from the load test for the visualizer, give a filename and path, you can use: ~/spline.jtl as a way to save results.

Running The Plan From The Command Line

Right now we have a plan and we want to report the results of our test as a .png graph and also a .csv. We will use the UTC date/time of when the load test began in the file name for both. We can accomplish this with the following psake script, which will do everything we need:

Invoking The Load Test

After we have loaded the psake module into our PowerShell session and we have configured all of our paths correctly, we can invoke the command that will run our plan and build a graph of the average request time along with a .csv file. This can be placed in an output directory that we can access or communicate to others who are interested. One useful way to do this type of testing is to have a continuous integration system run the LoadTest task every day. We can then easily see if our response times are increasing or decreasing in our development or staging environment over time.


Comments

No Comments

Post Comment

Prove you are human 13 + 3 =



Join my email list!



ryan
About Me

With over 15 years in tech, I've excelled as a senior software engineer, specializing in ASP.NET, C#, SQL, Azure, and front-end technologies. I've led diverse projects across various sectors, from startups to global corporations, particularly during my decade in the San Francisco Bay Area.


Sign Up With SoftSys Hosting! (My host)