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.
With only a few hours remaining of 2024, it is time to look back and take a tiny outlook on 2025.
A rather annoying error caught my attention a few weeks ago. Our SonarQube pipeline in Azure DevOps started to throw this error:
A few weeks ago, I upgraded my Synology DiskStation to the newest version of the DSM 7.2 branch. The upgrade warned about a few incompatibilities, but I used none of them – at least I thought. While the upgrade went through without any problems, it took a while to notice an odd new problem. When I tried to log in via SSH, all I got was the access denied message.
Strange, then the Passwordless Backup with Synology DiskStation worked as it did before, yet I could not connect with the same credentials.