While installing SQL Server on a new SSD, I run into a problem with the installer. Everything worked, except the add-on features I selected failed. Strange. But then SQL Server did not start, and I found this entry in the Event Viewer:
A quick hack to get a first shippable product out the door can survive a lot longer than you think. My little story shows you how things can end up if you do the right thing by pure chance.
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.