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.
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.
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.
While it is possible to use WinDbg to dive through your memory dump, it takes a lot of knowledge to do so. A much simpler approach is to use a commercial tool like dotMemory from JetBrains. This tool has a graphical interface that allows us to click through the dump and explore what objects lay around.
The dotnet-dump tool is a great help to create dump files. But even with an administrator account you can sometimes run into this error:
Another problem we may uncover with performance testing is a memory leak. Those nasty problems hide well inside our application, and they may only show up when our application runs for weeks. How can we force them out in the open without waiting for a month?
Last week we used BenchmarkDotNet to compare our improved method against the original one. Since it was faster, we changed the application to use the new code. The final part to close the loop, as my friend Daniel Marbach says, is now to measure the whole application once more to make sure that we indeed get a performance boost.
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.
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?
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#.