DOTNET: How to improve an application performance of DOTNET? A Complete Checklist

0. First principle: measure before tuning

Before touching settings:

• Use: PerfMon, dotnet-counters, dotnet-trace, Failed Request Tracing, IIS logs.
• Track at least:
  • Requests/sec
  • Avg/95th latency
  • CPU %
  • RAM / GC pauses
  • HTTP errors (4xx/5xx)
• Change one thing at a time and compare.

1. OS & Hardware-level optimizations

These are outside IIS but critical:

1. Use modern Windows Server (2019+ ideally) – better HTTP.sys, HTTP/2/3 support, TLS performance, etc.
2. Enough CPU & RAM; avoid constant >80% CPU.
3. Use SSD/NVMe for web content and logs.
4. Network:
   • Enable RSS/Receive Side Scaling, offloads (checksum, LSO) if appropriate.
   • Make sure NIC drivers are updated.
5. Power plan: set to High performance on servers.
6. Disable unnecessary background services and scheduled tasks that contend for CPU/IO.

2. IIS application pool tuning

2.1 .NET CLR & pipeline

For ASP.NET Core with ANCM:

• Use No Managed Code in app pool (since Core runs out-of-process) – avoids extra .NET overhead in w3wp.

For classic ASP.NET:

• Use Integrated pipeline mode (not Classic) for better performance & features.

2.2 Recycling

Recycling too often kills warm state and hurts latency:

• Disable time-based recycling (e.g., every 29 hours) unless you have a strong reason.
• Prefer recycling on:
  • Specific memory limits (if leak suspected)
  • Configuration changes (default)
• Use overlapped recycling and preloading to avoid cold start spikes.

2.3 Idle timeout & start mode

• For high-traffic / critical apps:
  • Set Idle Time-out higher or 0 (no timeout).
  • Enable AlwaysRunning + Application Initialization so app is always warm.
• For many small sites:
  • Keep idle timeout to auto-suspend low-traffic apps to save RAM.

2.4 Queue length & throttling

• queueLength (Application pool → Advanced settings):
  • Increase from default (1000) if you see 503.2 (queue full) and backend is still healthy.
• Consider CPU throttling only when you want fairness between sites; it can also become a bottleneck if set too low.

3. Site & connection-level settings

3.1 Max concurrent connections and limits

• Tune connectionTimeout, maxConnections, and request limits (Request Filtering → maxAllowedContentLength, maxRequestLength).
• Too low → users get 400/413; too high → risk of memory exhaustion during attacks.

3.2 HTTP/2 & TLS

• Enable HTTP/2 where possible – especially for many small static resources.
• Use modern cipher suites and TLS session resumption for lower CPU per SSL handshake.

3.3 Keep-alive & pipelining

• Keep-alive enabled to reuse TCP connections.
• Keep-alive timeout: balance between:
  • High enough to reuse connections
  • Low enough to avoid too many idle connections consuming memory.

4. Caching (the big win)

4.1 Static content caching

• Enable kernel-mode caching and static file caching:
  • Client cache: set long Cache-Control headers (public, max-age=31536000) for versioned static assets (CSS/JS/images with hashes).
  • IIS Output Cache / HTTP.sys: cache frequently requested static responses in memory.

4.2 Dynamic output caching

For pages whose output doesn’t change per-user:

• Use Output Caching:
  • Cache by URL + query string + headers as needed.
  • Use proper vary-by configuration (e.g., VaryByParam, VaryByHeader).
• For ASP.NET Core:
  • Use Response Caching middleware or application-level memory/Redis cache.
• Beware: wrong vary rules can show other users’ data → test carefully.

4.3 Partial caching

• For classic ASP.NET: use fragment caching for expensive controls/user controls.
• At app layer: cache heavy data (e.g., dropdown lists, configs) in memory/Redis so IIS doesn’t call DB every request.

5. Compression & content optimization

5.1 Static compression

• Enable static compression for text content (HTML, JS, CSS, JSON, XML).
• Don’t compress:
  • Already compressed formats (JPEG, PNG, MP4, ZIP, etc.).
• Make sure compression cache directory is on fast disk.

5.2 Dynamic compression

• Enable dynamic compression carefully:
  • Good for APIs returning JSON/HTML.
  • Watch CPU – heavy dynamic compression + high concurrency can become bottleneck.
  • Use thresholds (e.g., only compress responses > some size).

5.3 Brotli / newer algorithms

• On newer Windows / reverse proxies: enable Brotli for extra savings, especially on text content (if supported by your stack).

6. Modules, handlers & pipeline trimming

Every extra module = extra work per request.

1. For each site:
   • Go to Modules and remove what you don’t need:
     • WebDAV, ASP, ISAPI, CGI, etc., if unused.
2. For static-only sites:
   • Disable ASP.NET, authentication modules, etc.
3. For API-only sites:
   • You might not need session state / forms auth / etc.

This reduces CPU per request and speeds up pipeline.

7. Logging & diagnostics tuning

Logging is essential but can slow you down if misconfigured.

1. W3C access logs:
   • Use separate log directory on fast disk.
   • Avoid logging fields you don’t need.
   • Roll logs daily or by size.
2. Failed Request Tracing (FREB):
   • Enable only for troubleshooting specific status codes (e.g., 500, 503).
   • Turn off once done.
3. Don’t write massive logs from app to disk synchronously; use async logging + batching (Serilog/Seq, ELK, etc.).

8. Request filtering & security (for performance & safety)

Tuning security helps performance by rejecting bad traffic early.

1. Request Filtering:
   • Limit maximum URL length, headers length, body size.
   • Block unwanted file extensions, methods, verbs.
2. IP restrictions / WAF:
   • Use IPRestrictions to block abusive IPs.
   • Use external WAF / reverse proxy (F5, Nginx, Azure App Gateway, Cloudflare) to filter bots/attacks before IIS.
3. Authentication:
   • Avoid enabling multiple auth schemes unnecessarily (e.g., Windows + Anonymous + Basic).
   • Use the lightest authentication compatible with your requirements.

9. Pooling & concurrency strategy

9.1 Web gardens (multiple worker processes in one app pool)

• Generally NOT recommended for ASP.NET / ASP.NET Core apps that rely on in-process state (Session/InMemory cache).
• Use scaling out with multiple servers or load balancer instead.
• Only consider web gardens when:
  • Stateless app
  • You understand affinity/load-balancer behavior.

9.2 Multiple sites on same server

• Make sure heavy sites don’t starve lightweight ones:
  • Separate app pools.
  • Use CPU limits or move heavy sites to dedicated server.

10. Content & front-end optimizations (indirect IIS wins)

These don’t change IIS itself, but dramatically reduce its load:

1. Use CDN for static assets (images, JS, CSS) → fewer hits to IIS.
2. Minify & bundle JS/CSS.
3. Use image optimization:
   • WebP/AVIF where possible.
   • Proper sizing; avoid 4K images for thumbnails.
4. Reduce number of HTTP requests (sprites, bundling, HTTP/2 multiplexing).

Less work for IIS = better performance and lower cost.

11. ASP.NET / ASP.NET Core specific tuning (on top of IIS)

1. GC mode:
   • Use Server GC for high-throughput server apps.
2. Thread pool tuning only when necessary (usually defaults are fine).
3. Avoid blocking calls (.Result, .Wait()) on async flows → thread starvation.
4. Optimize EF Core / DB access:
   • Use pooling, compiled queries, proper indexes.
5. Cache config & lookups; avoid reading from disk/DB each request.

IIS is only part of the chain; app inefficiencies dominate many real issues.

12. Scaling strategies with IIS

When vertical tuning isn’t enough:

1. Scale out using:
   • Multiple IIS servers behind a load balancer (hardware / software / cloud LB).
2. Use sticky sessions if you rely on in-process session state; otherwise move session state to:
   • SQL Server / Redis / distributed cache.
3. Use blue–green deployments or slots (e.g., Azure App Service) to avoid downtime during releases.

13. A simple priority checklist (what to do first)

If you want a quick actionable order for a new/slow IIS app:

1. Measure (PerfMon + app metrics).
2. Enable static & dynamic compression (watch CPU).
3. Set caching headers for static content.
4. Trim unnecessary IIS modules.
5. Configure app pool:
   • No Managed Code (for ASP.NET Core).
   • Disable frequent recycling.
   • Increase queue length if necessary.
6. Enable Application Initialization + AlwaysRunning for warm startup.
7. Move logs to fast disk, trim logged fields.
8. Add CDN for static content if traffic is high.
9. Optimize DB calls and app-layer caching.
10. If still slow: consider scaling out with load balancer.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.