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.
With the utter disaster of the NuGet auditing out of the picture and a fix for the missing CSS files in place, I finally could work with Visual Studio and see which features I found interesting in the release note do indeed add some value in my daily work.
A few weeks ago, I noticed a nice feature of GitHub: we can create links to code on GitHub and highlight the lines we talk about. I find this a great help and show you in this post how to do it.
Last week we addressed the most annoying problem of Visual Studio 17.12, the messed up NuGet audit for vulnerabilities. This gives us now the chance to talk about the second big problem we may run into in Visual Studio 17.12: the missing CSS and JS files when we build our web applications.