You don’t have to performance test if you are not bothered about the performance of your application; this is the only reason, if you are bothered and you want to make sure your customers get the best possible experience then it is wise to do some.

Timers in JMeter are incredibly important when it comes to the balance and pace of your performance tests, we are going to look at the Timers that ship with the standard JMeter installation in this Blog post but there are others that are available as a Plugin and hopefully this post will encourage you to investigate these further.

Regression Testing, as all Quality Assurance professionals know, is ensuring that previously developed and tested software continues to operate after a change. Performance Regression being a subset of regression testing as a discipline is therefore ensuring that previously developed and tested continues to meet its performance criteria after a change.

This post is about Kafka and the process I have been through recently writing a performance test for an application that subscribes to messages from this technology. The test I ended up with was in the end very straightforward but there were several hurdles that took a while to resolve. I hope that reading this post will hopefully help you avoid them.

It’s been some time since our latest major release, in fact OctoPerf v12 is probably our biggest/longest coming release to date. There’s of course been a couple of minor versions this summer and we’ll also cover them but first let’s focus on the new killer features: the scheduler, alerting through slack/mail and a better UI for the menus. The scheduler is the first item left on our original roadmap (back when OctoPerf was still called jellly.io).

“JMeter is old technology”, I hear this a lot. “Let’s use this tool or that tool instead of JMeter as it’s the latest”, I hear this a lot. “We need a lightweight tool without the GUI interface to write our tests as that will make us more agile”, I hear this a lot.

This article is the fourth part of a series of tutorials dedicated to Gatling Load Testing. Kraken is used to ease the debugging of Gatling simulations and to speed up the process of load testing a fake e-commerce website: PetStore. We will focuse on POST requests and script modularization: In the previous blog post we created a realistic Virtual User that browses the store without buying anything.

While developing Kraken’s frontend I quickly stumbled upon performance issues with Angular Material tree when too many nodes where opened. Kraken is an open source load testing IDE. As such, it displays a tree of directories and files used to script the load testing scenarios: You can have a look by creating a free account on the demo or check the source code of the UI on GitHub. It uses the latest version of Angular and components provided by Angular Material such as the tree.

This third version of Kraken represents one more step towards a load testing solution suitable to teams and enterprises. Kraken can already be installed on your own Kubernetes cluster thanks to Helm charts: You own all data and can handle the security inhouse. But until now it was lacking users management, making it cumbersome to use it for a team of performance testers. This point is now addressed in the version 3.0 thanks to Keycloak.

OctoPerf’s report engine provides many graphs to sort and presents test metrics in a comprehensive way. We’ve tried to improve it over the years so that you can access critical information very quickly. But requirements vary from one project to the other. In this post we will look at how you can configure the report to show you preferred metrics, and also all the shortcuts you can take to achieve this goal.