It has been almost eight years since I first wrote a blog on IIS best practices. During this time, several new versions of IIS have arrived, some reached end of lifecycle; we were introduced a new development platform called .NET Core; a new HTTP version… And after eight more years of experience on a variety of customers and environments, finally I thought it was time for an update. Hope you enjoy it :)
See here for the old version.
For a very long time, I have been asked for a document on IIS best practices. There are some blogs/articles on the Internet, but I could not find a complete one. Actually, the main problem here is that there cannot be “best practices” for a web server. A web server is just a hosting platform for applications, and, each and every application has its own needs. Therefore, in many cases, you will not have one universal best practice.
Having these said, I tried to gather a list of things one should check while configuring an IIS server (and an application on IIS). I should say that these are my own thoughts based on my own experience. It may be possible that you will find some resources mentioning just the opposite of what I say. For such cases, consider your applications specific needs and decide accordingly.
Most of the below mentioned settings or recommendations apply to the web applications hosted on cloud solutions (like Azure Web Apps) and some will already be in-place. Especially some of the performance best practices listed below would help you keep your cloud costs as low as possible.
One more thing before we get to my recommendations: Keep in mind that web servers are just hosting platforms for your applications. They can only be as secure and as performant as your code. Therefore, do not expect the below list to address and resolve all your problems.
Application Pools <applicationPools>
Application Pool Identities
Group Managed Service Accounts Overview
What's New for Managed Service Accounts
Recycling Settings for an Application Pool <recycling>
If you are confident that your application does not have any resource leak issues and if your application pool is recycled during deployments every now and then, you might consider totally disabling recycling.
Failure Settings for an Application Pool <failure>
HTTP Logging <httpLogging>
Adding Custom Fields to a Log File for a Site <add>
Log Parser 2.2
Collect IIS logs in Azure Monitor
Error logging in HTTP APIs
Collecting User-Mode Dumps
HTTP Compression <httpCompression>
Configure Windows Defender Antivirus exclusions on Windows Server
Default Document <defaultDocument>
Transport Layer Security (TLS) best practices with the .NET Framework
Content Security Policy (CSP)
HSTS Settings for a Web Site <hsts>
OWASP Secure Headers Project
Request Filtering <requestFiltering>
Remove Unwanted HTTP Response Headers
Protecting Connection Strings and Other Configuration Information (C#)
processModel Element (ASP.NET Settings Schema)
ASP.NET Thread Usage on IIS 7.5, IIS 7.0, and IIS 6.0
In-process hosting model
Middle Ground between Server and Workstation GC
smpAffinitized and smpProcessorAffinityMask
IIS 8.0 Multicore Scaling on NUMA Hardware
Debug Mode in ASP.NET Applications (the article is very old, but it is still valid for all .NET versions)
Troubleshooting Failed Requests Using Tracing in IIS 8.5
Trace Failed Requests Logging for a Site <traceFailedRequestsLogging>
How do I use HTTP/2?
Debug Diagnostics Tool
Azure Monitor overview
What is Application Insights?
\Processor Information(_Total)\% Processor Time
\.NET CLR Exceptions(w3wp)\# of Exceps Thrown / sec
\.NET CLR Memory(w3wp)\# Gen 0 Collections
\.NET CLR Memory(w3wp)\# Gen 1 Collections
\.NET CLR Memory(w3wp)\# Gen 2 Collections
\.NET CLR Memory(w3wp)\# Induced GC
\.NET CLR Memory(w3wp)\Process ID
\.NET CLR Memory(w3wp)\#Bytes In All Heaps
\ASP.NET\Request Execution Time
\ASP.NET Applications(*)\Requests Executing
\Process(w3wp)\% Processor Time
\WAS_W3WP(*)\Total Health Pings.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.