Skip to content


Scalability Testing

We are going to look at scalability testing in this Blog Post. On paper scalability testing is simple because all you are doing is increasing the load, but there are some common pitfalls that can be easily avoided. So you need to really understand what you are trying to achieve before you start.

Basic Principles

Let’s start with the basic principles: A scalability test is the process of systematically increasing load on your application under test until

  • You reach your goal in terms of desired load,
  • The system starts to become unresponsive.

If you want to get a clear picture of whether your application does scale then it is important to run your scalability test on an environment that is consistent with production, or how you expect production to be.

Clearly one of the objectives of a scalability test is to size the environment so you must also have the flexibility to increase the resources in the environment in which you are running this test.

Chaotic Performance Tests with JMeter

Building performance tests that conform to a very specific level of load and concurrency is a standard approach to performance testing.

You determine your peak levels of load and concurrency, and you build a test that meets this.

You build soak test and scalability tests that conform to pre-determined levels of load and concurrency, and you execute these alongside the other scenarios you build to meet your performance requirements.

This is the correct approach and conforms to most organisations approach to performance testing and something you should always do; but in addition its also a good idea to build performance tests that change on each execution and put your application under a random ever changing load profile as it is not uncommon for application usage to change when new features are added or if migrating to a new solution therefore randomising your performance testing can provide you useful information on how your application will react to conditions that do not conform to your standard approach.

This blog post will look at how you can make your JMeter tests more chaotic using a variety of samplers, timers and a beanshell server.

Performance Testing GraphQL with JMeter

In this Blog Post we are going to look at the GraphQL HTTP Request sampler and look at how GraphQL requests can also be made using a HTTP Request sampler in case you are for some reason restricted to an earlier version of JMeter (the sampler was only introduced in JMeter 5.4).

We will also look at some of the principles of GraphQL.

If your application under test comprises of a GraphQL service, you are going to have to understand how to test it and some of the performance considerations that surround performance testing of GraphQL.

JMeter HTTP Request Sampler

There are many samplers that JMeter provides but I am willing to bet that the HTTP Request samplers is the most frequently used and, in this Blog Post, we are going to look at how this works and how it can be configured.

HTTP Request

Before we look at the sampler lets look at the option available to us in the HTTP Request drop down, while you probably don’t need to understand these in order to test you application using JMeter it can be useful.

These request methods indicate the action to be taken on the resource specified in the Web Server section of the sampler and are sometimes referred to as HTTP verbs, these are defined by The World Wide Web Consortium (W3C). W3C is the main international standards organisation for the World Wide Web.

There are 5 main methods used in modern API’s these are:

Method Description
GET The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.
PATCH The PATCH method is used to apply partial modifications to a resource.
POST The POST method is used to submit an entity to the specified resource, often causing a change in state or side effects on the server.
PUT The PUT method replaces all current representations of the target resource with the request payload.
DELETE The DELETE method deletes the specified resource.

Performance Testing Web Sockets with JMeter

In this post we are going to look at WebSockets, specifically how JMeter can be used to test them.

Web Sockets are not supported natively by JMeter but there are a couple of Plugins that you can use that work very nicely.

One of them is called JMeter WebSocket Sampler by Maciej Zaleski and information on the library can be found here.

The second and the one we will use for our post is also called JMeter WebSocket Sampler and is by Peter Doornbosch, more information on this Plugin can be found here.