Skip to content

Blog

Parting Thoughts on Performance Testing

After spending the last four months diving into performance testing and hunting down memory leaks, this series comes to an end. Let’s take a moment to reflect on the key insights and explore some ideas you can try on your own.

Reduce Infrastructure Costs Guided by Performance Testing

When we talk about performance tests, we usually do it with the goal of making our applications faster. However, we can also focus on the reduction of resources we need to deliver the same performance. If we do not want to blindly meddle with our infrastructure, we need to run our performance tests to guide the optimisation. Let us explore our options.

The Strange Memory Leak in .Net 8

Last year we moved our applications from .Net 6 to .Net 8. It was much less work that it was to move from .Net 4.8 to .Net 6. The migration itself was straightforward, and we could put our updated application into production without any issues. That was until a week later when we got this strange error:

Application '/LM/W3SVC/11/ROOT' with physical root '...'

hit unexpected managed exception, exception code = '0xe0434352'.

First 30KB characters of captured stdout and stderr logs:

Out of memory.

Validate Code Improvements With BenchmarkDotNet

After we found a slow method on the hot path of our application, it is time to improve the code and make sure that the change is indeed faster. Here we must dive into the next challenges and do the hard work of figuring out where exactly we lose time or waste too many resources. Let us find a helpful approach and explore BenchmarkDotNet, a tool that helps us to create benchmarks of our improvements.

Find the Hot Path With dotnet-trace

Before we jump into optimising our application, we must make sure that the bottleneck we found is indeed an important one. If we optimise a part of the application that is seldomly used, we may waste a lot of time without improving the performance at all. The same is true for a part that is often used but faster than the real bottleneck somewhere else.

We can use the hot path to find the important spots in our application. But what is that and how do we find it?

Complex Load Tests With NBomber

With Bombardier we can run a load test against one single endpoint at a time. While this can help us to find performance bottlenecks on a page, it is not the most realistic load pattern for an application. If we want to know if our shopping card still works if hundreds of users hit the entry page, we need a different tool. I found in NBomber a tool that offers the needed flexibility and even better, we can keep writing our tests in C#.