Skip to content

Load Testing Blog

Run JMeter tests in Java code

In this blog post, we will run JMeter tests from code. First we will look at how we can create an IntelliJ project in Java to build a JMeter performance test.

Once you understand how JMeter tests in code can be written you can start to build tests in your development code base to compliment unit tests or functional tests written by developers during the creation of application and services.

In a DevOps world it is the responsibility of developers to support all development effort with a suitable and robust set of tests that are run as the code is built and deployed into the various non-prod and prod style environments and your performance tests can sit alongside these.

We have chosen to use IntelliJ due to its widespread use and we have chosen to create a Maven project to allow us to import the JMeter dependencies.

Clearly your preference may be different, but the principles remain the same.

We will build and execute this as a stand-alone project to demonstrate the principles but once you are happy with how it works there is no reason you cannot build similar performance tests in your application development codebase or even pair with the development teams to build a performance capability in your deployment pipelines.

How to configure and use JMeter logging

We are going to look at how JMeter outputs to both the log panel in GUI mode and the log file in non-GUI mode. We will look at the properties relating to the GUI log panel and the Appenders and Loggers that determine what data is output and at what level the logs are output at.

JMeter uses log4j to provide its logging mechanism and from the log4j website:

Log4j has three main components: loggers, appenders and layouts. These three types of components work together to enable developers to log messages according to message type and level, and to control at runtime how these messages are formatted and where they are reported.

We will look at how Jmeter configures Appenders and Loggers separately but they work together to produce the logged output.

The logging level can be set in several ways:

  • From the log4j2.xml file,
  • From the menu,
  • From the command line.

We will explore all of these during this post. Note that you can download the sample JMX here.

Use JMeter to create a website crawler

The idea behind this blog post originated when we updated our documentation after the release of our new UI. We had to identify all links used in the OctoPerf website and update them from to With more than 250 blog posts at the time I'm writing this one, you can see how this could prove challenging. And of course the twist is that we also took this opportunity to reorganize the documentation so it's not as simple as a search and replace of the domain.

This got us thinking on ways to automate it, because a lot of third party links could also be broken and of course one of those ways is to use OctoPerf itself to execute JMeter tests that will report on all the broken links.

Angular Performance Optimization - *ngFor trackBy

Yet another blog post dedicated to Angular performance optimizations. This time we will use the trackBy function of the *ngFor structural directive to optimize changes made to the DOM tree and thus optimize performances when updating a large list of items.

The use case is still a simple web application that displays a list of books. Now, a form will let the user insert a book in the list, and Delete buttons will let the user remove items from the list:

Books list create from

Angular Performance Optimization - Web Workers

In a previous blog post we identified a potential performance issue caused by calling a method from the template of an Angular component and saw that time-consuming operations could still be a problem even for an optimized application.

Prime Number Application

Using the same use case - a very simple application consisting of a number input that compute the next prime number -, we will now study how to externalise long-running operations to a web worker.

Web workers makes it possible to run a script operation in a background thread separate from the main execution thread of a web application. The advantage of this is that laborious processing can be performed in a separate thread, allowing the main (usually the UI) thread to run without being blocked/slowed down.