Load testing strategies for your ASP.NET web applications

Posted: (EET/GMT+2)

 

If your ASP.NET application works well with one user, the next question is how it behaves with one hundred or one thousand.

Load testing helps identify bottlenecks before production traffic does. In practice, the first issue is often not CPU usage, but database connections, thread pool starvation, slow external APIs, or request queue growth.

Start by testing realistic endpoints instead of only lightweight health checks.

For example, test:

  • database-backed API endpoints
  • authentication flows
  • file uploads
  • search operations
  • larger JSON responses.

A simple way to generate load is with tools like wrk (see here) or bombardier (see here). If you have wrk installed, you could run the following on your terminal:

wrk -t4 -c100 -d30s https://localhost:5001/api/orders

Or if you prefer Bombardier:

bombardier https://localhost:5001/api/orders

Tip: use a Release build of your ASP.NET application during load testing. Debug builds usually do not represent real runtime behavior.

While the test is running, monitor the application itself. For ASP.NET Core applications, dotnet-counters (more information here) is a quick way to inspect runtime metrics.

dotnet-counters monitor --process-id 1234

Useful counters include:

  • CPU usage
  • GC allocation rate
  • thread pool queue length
  • request duration
  • exceptions per second.

Another good strategy is increasing load gradually instead of jumping directly to peak traffic. For example, first ten, then twenty five, after that fifty, one hundred, and so on.

This makes it easier to identify where response times start increasing or errors begin to appear.

Also remember that the ASP.NET application is often not the first bottleneck. SQL Server, Redis, authentication providers, storage services, or external REST APIs may become slower first.

It's also a good idea to test with production-like configuration whenever possible:

  • TLS enabled
  • real database size
  • reverse proxy enabled
  • container memory limits
  • production logging settings.

If your application runs in Docker or Kubernetes, monitor container memory usage as well. Container restarts caused by memory limits can appear as random instability under load.

Load testing is less about finding the exact maximum request count and more about understanding how the application behaves under increasing pressure.