Skip to content

JMeter

  • in JMeter
  • 12 min read

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.

  • in JMeter
  • 14 min read

Performance Testing, Artificial Intelligence and Machine Learning

We are going to look at how performance testing can work hand in hand with Artificial Intelligence and Machine Learning:

  • We will look at how we can use data gathered from performance test scenarios during execution to determine what functionality and what concurrent volumes and load profiles we should be testing.
  • We will use very simple mathematical models to do this in conjunction with a very simple database model with several manual steps to simulate the machine learning.

As there are many Artificial Intelligence solutions to choose from and for the purposes of this post this is the easiest way to discuss the principles of Artificial Intelligence working with performance testing rather than discussing a particular framework.

  • in JMeter
  • 13 min read

Continuous Delivery Test Reporting

We have spoken in a previous blog post about documentation about how we believe that if you are building performance tests that support either Continuous Integration or Continuous Delivery then having to produce performance testing documentation before and after each test does not fit with this methodology.

This got us to thinking that if we truly want to use an agile framework and continually push code to production then we need to also consider how we monitor and report on our performance test results produced from our testing tools.

If you have an agile testing process, then you will have functional tests built into this deployment process that run in each environment and if you have a mature robust process then this process deploys to production with no manual intervention if all the functional tests have passed along with any deployment checks.

Now in reality we need to have a performance testing stage in this process as well as each release needs to go through a performance test, whether that is a full suite of peak volume, soak test, scalability tests scenarios or whether that is a regression tests of core functionality.

And this is the bit that we are going to discuss in this blog post because if your organisation wants to push code directly to production then you do not have the luxury of running your performance test, analysing the results and writing up a report to be signed off.

  • in JMeter
  • 15 min read

Updating JMeter Performance Tests with an XML parser

When building performance tests, we all understand the value of using properties or variables to store static values outside of our tests. This ensures that any changes to these values need only be made in one place rather than having to make these changes in many tests.

Sometime though you may have inherited a suite of JMeter tests, or you were ** under pressure to develop these tests** and in order to do so you hardcoded values in your tests. This means that if anything changes, an endpoint or the server-name or even the payload of a sampler then you need to make changes to these static values in your tests.

  • in JMeter
  • 10 min read

How to load test LDAP with JMeter

We are going to discuss how we can test the Lightweight Directory Access Protocol (LDAP) using JMeter, the principles of LDAP can be quite complicated as their origins come from the X500 specification which documents a suite of protocols developed by the International Telecommunication Union in the 1980’s.

It is likely that you have heard of LDAP as the directory protocol used to underpin Active Directory (AD) which is a directory service for Microsoft and normally is used by many organisations to support user authentication and role profiles for company networks.

It is important to understand that LDAP is not exclusive to Microsoft but does allow users to query AD and authenticate access to it.

In order to demonstrate how we can test LDAP using JMeter we are going to use an Online Test Server provided by Forumsystems which means that should you wish to follow this tutorial but don’t have access to a LDAP server you can. If you need to look at the solution, the JMeter project can be found here.

A limitation of using this online LDAP test server is that we only have read-only access meaning we can only test the following functions:

  • Bind
  • Unbind
  • Search
  • Compare

But JMeter also offers the ability to:

  • Rename
  • Add
  • Delete
  • Modify

The LDAP entries which we will be unable to demonstrate using this service but nonetheless we will provide some examples of these test types.