Prepare Your ASP.NET Core Application for Performance Testing

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.

Use the .Net version you run in production

While Microsoft once a year explains by how much the newest .Net version got faster, the minor and patch versions of .Net often improve performance as well. Therefore, make sure that you use the same version you run in production:

dotnet new globaljson --sdk-version 8.0.403

Disable the console logger

A great time waster is the console logger, that comes by default with every ASP.NET Core application. We cannot disable it, so we need to remove all loggers at the beginning of our configuration and then only add the loggers we need:

var builder = WebApplication.CreateBuilder(args);

builder.Logging.ClearProviders();

This change improves the performance, but it brings another problem. When we now start the application, we do not get any feedback if it is ready or not. Instead of wasting time with waiting on an output that never comes, we can make a tiny modification and attach a Console.WriteLine() to the application lifecycle:

app.Lifetime.ApplicationStarted.Register(() => Console.WriteLine("Application started. Press Ctrl+C to shut down."));
app.Lifetime.ApplicationStopping.Register(() => Console.WriteLine("Application is shutting down..."));

app.Run();

We now see when the application is ready for our tests without slowing us down with the console logger.

Never run it in debug mode inside Visual Studio

The debug mode is great to debug the application, but it is a nightmare when we try to run our performance tests. All the debugging symbols and the overhead of the attached debugger will slow the application down. A thing we do not want when we try to figure out how fast the application can run.

Make sure that you compile the application in release mode and that you run it that way outside of Visual Studio:

dotnet build -c Release
dotnet run -c Release

How bad can the debug mode be? Let us look at these results for the same settings of Bombardier:

Scenario	Total Req. in 10s .Net 8	Total Req. in 10s .Net 9
With debugger, inside Visual Studio	191	144
With debugger, on CLI	42430	47606
Without debugger, on CLI	50054	59324

The results show how massively slower the debug mode is when you run it in Visual Studio. The attached debugger slows the application down by orders of magnitude.

If we start the application on the command line, the debug mode can still be 15%-20% slower than the release mode. Maybe you are lucky, and the difference is neglectable. Nevertheless, always run the application in the release mode on the command line.

Start the application with HTTPS

HTTPS gives an additional performance improvement. Should you run the application on your developer machine, make sure you activate HTTPS:

dotnet run -c Release --launch-profile https

Stop everything that can influence the measurement

The less application run on the test server, the better it is. Everything that runs that is not part of the application you test will slow it down. Whenever you can, stop everything else until you finished the performance testing.

If you run the measuring tool on your developer machine, make sure you close all other applications, including Microsoft Teams that runs in the background. Should you have a laptop, make sure you plug-in the power supply. Otherwise, you run on the energy saving plan and that is terrible for reliable measurements.