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.
To figure out if our application can handle a certain load, we need a way to produce that load. That is the purpose of Bombardier, a powerful HTTP benchmarking tool designed to test the performance of web servers. Written in Go, it leverages the fast and efficient fasthttp library, making it an excellent choice to flood a web server with requests.
In the world of web development, performance testing often feels like an afterthought, much like security and maintainability. We are going to do that later – a later that never appears.
However, just as maintainable code is crucial for long-term success, performance testing is essential to ensure that our web applications are robust, responsive, and ready to handle real-world demands.