In this blog post we are going to look at using JMeter to support business testing in production.
This is a slightly different topic to the one discussed in this post on testing in production.
The one in the link above is around running your performance testing in production for reasons that are discussed in that post.
This post is going to focus on how you can leverage your performance testing tools to support this activity, as discussed above we will focus on JMeter in some of the examples.
But any load testing tool, or even functional testing tool, can provide the same benefits.
In this blog post we are going to look at how we can use our performance tests to act as Sanity Test. We have touched upon the subject in one of our blog posts on the hidden benefits or performance testing.
This post will however look to provide more detail on the subject and provide guidance on how you can accomplish this.
We are not suggesting that you write a set of JMeter tests to act as sanity tests for our application under test as that would not be that beneficial. There are much better ways to write sanity tests for applications in the form of Unit Tests in code or by using a functional testing tool such as Playwright.
What we are going to investigate is how you could use already existing JMeter tests to also support Sanity testing. If you have a set of performance tests or are in the process of creating a set of performance tests for a particular project or programme, then to build them in such a way that they can double as Sanity tests would be beneficial.
We will look at how when building a test, you could also add some additional logic to give your performance tests the capability of supporting an application Sanity test. If you have a set of tests already that you have built, then by following this post will show you how these existing assets can be updated to support Sanity testing.
In this blog post we are going to look at how we take a postman request or collection and translate these into JMeter tests. When web services are being build it is common for Postman to be used to test the endpoints. This is done by:
Development teams
Wider Quality Assurance community
Business users
Product owners
the list goes on.
What naturally happens during programmes where web services are part of the design is that postman requests and collections are built and grow to support all manner of requirements. Using these collections to quickly build your performance tests can save you a significant amount of time and effort when it comes to understanding the web service you are testing along with the payload that the web service expects.
You will find that in some cases you can inherit a fully functioning set of web service requests that support all your requirements from a performance testing perspective.
In this blog post we are going to be looking at the Throughput Controller. Its name is a little misleading as it does not control the throughput in terms of managing load across the duration of a test, this is handled by elements such as the Constant Throughput Timer.
The Throughput Controller can support you in building quite complex scenarios especially when coupled with other Controllers and we will explore this in this blog post as well as looking at how this Controller can provide benefit in real-world performance testing scenarios.
OctoPerf support this behaviour natively on their SAAS platform through the use of the Flow Control Action that can support the same patterns of behaviour that we will discuss in this blog post.
Let’s create a JMeter test to demonstrate how this Throughput Controller Works. We will use a set of Dummy Samplers to achieve this.
If we create this test where we have 2 Samplers:
Sampler A
Sampler B
With Sampler B being a child of a Throughput Controller.
We can see that we have a single Thread with the Loop Count set to 10.
This blog post is about testing microservices and distributed systems with JMeter. It will focus on the principles of performance testing applications that are architected this way. We will not look at which JMeter samplers to use in order to generate a load against microservices or how to configure these samplers.
This post will consider best practise and consideration in designing your performance testing when faced with these applications.
Let’s just remind ourselves what the definition of microservices is, be mindful that there are many definitions that vary, but in principle:
Microservices are smaller, loosely coupled services that you can deploy independently. Here, “services” refer to different functions of an application.
In a microservices architecture, an application’s functions are divided into many smaller components serving specific purposes. These components or services are fine-grained and usually have separate technology stacks, data management methods, and databases. They can communicate with other services of the application via REST APIs, message brokers, and streaming.
Microservices are a way of structuring an application as a collection of small, independently deployable services that communicate with each other over a network. This is different from the traditional monolithic architecture, where all components of the application are tightly coupled and run as a single unit.
The way microservices are called depends on their implementation, they are commonly scripted in JMeter using a HTTP Sampler or a GraphQL Sampler both of which have OctoPerf blog posts which can be found here and here.
If the microservices you are testing are accessed in a different way then you will probably find a post on the protocol on our Blog Post pages, which can be found here.
If you are unable to find one, please get in touch and we’ll look at writing one.
