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#.
For data-intensive applications, ensuring that the code is fast is not enough; we need realistic data too. Without it, optimisations may fail as soon as we use our application with real-world data volumes. Let us explore our options for creating realistic test data.
Last week we explored tools like Serilog and OpenTelemetry to see what goes on in our applications. But we can only add these tools if we can modify our application. If this is not an option, we need another approach.
Thanks to the .Net diagnostics tools that Microsoft build around .Net, we can peak into our applications without modifying any code. That makes these tools a great help in any situation, even if we could change the application. Let us dive right into them.
Bombardier shows us the view from the outside and answers the question on how fast our application responded. But what happens inside the application? Does everything work as expected? Or did the application only return success as a status code but failed internally? Let us explore our options to find out what is going on.
We covered Bombardier, the tool to run the performance tests and prepared our application to give us useful results. However, that is not enough to get good performance tests. As soon as we start measuring, we run into new problems.
It is time to take a deeper look at the act of measuring itself and what can go wrong if we are not careful.
We can waste a lot of potential performance in our applications with just a few misconfigurations. Let us make sure we do not fall into those performance traps and instead give our application the best possible start.