Skip to content


Modularisation in JMeter

The key to all good automation is modularisation which is effectively isolating small chunks of your application under test into separate tests and then re-using these smaller chunks in your larger, more complicated tests. Example of good candidates for modularisation are logon and logoff as well as any other high-volume journeys through your application such as search functionality.

The rationale for this approach is that if these high volume common functional activities change you only need to make the update in a single test rather than in multiple tests. If your business functionality is only used once in a single script rather than many scripts it makes no sense to modularise it but if it is used twice, or more, then it should be considered.

Sample JMX files for this tutorial are available for download:

Load Profiles in Performance Testing

When we think of performance testing we normally think of thousands of requests with thousands of users generating huge volumes on our application under test or increasing the load until the application under test fails or runs out of resources.

This is not a good approach when determining load for your performance tests for several reasons and can in some cases render your performance testing meaningless.

This post will outline some of the pitfalls that are commonly made when it comes to generating load and will look at ways to suggest improvements to your approach to load profiles.

Using custom JAR files in JMeter

JMeter has many plug-ins and downloadable JAR Files you can use to support your testing, it is also possible to write your own custom Jar files and use these as well.

Why would you want to do that, you may say, well whilst it is unlikely that you would need to create anything too complicated.

You may feel the need to create utilities to support your own in-house performance testing or just something to make your testing process easier.

We could easily write a custom Jar file to push the results of test run to any reporting tools your organisation uses, if they expose their API's, at the end of the test execution cycle.

Alternatively, you could write something that sends your results to a mail server or web server for the purposes of results distribution.

For the purposes of this post lets imagine a situation where your company has a dashboard technology that displays the status of development builds or testing progress through a series of APIs, there are many examples of these type of status boards and they are common in many technology departments.

And let’s write a JAR file to output our JMeter test results in the form of JSON which can be sent to this imaginary endpoint we will then use the Custom Class we create in a JMeter test script.

Let’s get started!

Asynchronous API Performance Testing with JMeter

The principles behind performance testing API’s does not differ from the principles behind the performance testing of any application.

Many API’s however are Asynchronous and a valid response from the API does not necessarily mean the transaction is complete which can cause a problem when measuring the performance of API’s.

There are however ways around this and we will explore these in this post.

Sample JMX and DB files for this blog post are available for download:

Simple Way to Create Complex JMeter Scenarios

Creating complex performance testing scenarios in JMeter can be a complicated but necessary problem you will encounter as you build tests to mirror real user behaviour in your testing.

There are many add-ins that can support you in the creation of these scenarios. Which is good if they do what you want them to do. But if you want the flexibility to build tests without the limitations of 3rd party add-ins then there are several techniques you can use which come with the standard JMeter install.

All you require is a bit of imagination, a basic understanding of Groovy and the JMeter Switch Controller.

The resulting JMX script can be downloaded here.