As I mentioned before, one of the things we had a particular interest in addressing with this release of IIS as part of Windows Server 2012 R2 was its scalability when handling a large number of sites. A key ingredient for this is what we call site “activation” or “registration”. This refers to the interaction between IIS and the Windows HTTP protocol stack (http.sys). When the system loads and the various services start, the HTTP stack and IIS work together to establish queues, which listen for incoming requests.
With Windows 2012 released last year, as well as earlier versions of Windows, IIS was designed to “activate” (create queues) all the sites that were configured on it on startup. This is no big-deal if you have just a few sites on your server, but if you have hundreds or thousands of websites, this takes a while and consumes a lot of memory and kernel resources. To be clear, this does NOT refer to the action of spinning up a worker-process for a site. Creating a worker process only happens when a request for a site is received.
If you are running a large number of sites on a single server, you will be happy to know that we have implemented a new feature called Dynamic Site Activation. When it is enabled, IIS doesn’t create queues and bindings for all sites in HTTP on startup. Instead, IIS creates one queue which listens for everything, and will create specific queues for specific sites only when a request actually arrives for it. This allows the IIS service to start much faster, and consume a lot less memory.
As I said, this feature is more relevant for servers running a large number of sites, and so we have configured this to have a threshold of 100 sites. On servers with less sites than that, this will be off by default. If the server does have 100 sites or more, it will not create the queues for them upon startup, and if you observe the kernel paged pool memory usage, it should be quite visible. It will also result in IIS taking noticeably less time to restart as it won’t need to release all of the registered queues and bindings with HTTP.
If you are running a lower number of sites, you can configure the threshold to a lower value, though I should note that the performance difference is lesser on a smaller number of sites, and at some point it may even be a tad slower.
To see this feature in action, run the command netsh http show servicestate on your server. This command shows a list of queues (sites that are “registered”). For example:
On a Windows 2012 server, you would see a list of all the site you have configured. On a Windows 2012 R2 server with DSA active (has a number of websites that is over the threshold), the number of queues will typically be lower, and the command will only show the registered queues. If you don’t have a lot of sites and you want to explore this, simply set the threshold to a number lower than your total number of sites, and restart IIS. The configure this:
1. In the IIS console, Go to Configuration Editor:
2. Go to weblimits
3. Change dynamicRegistrationThreshold value to one that suits your needs:
4. Restart IIS
Like this feature? Go ahead and download the preview of Windows Server 2012 R2 here. We here in the IIS Dev team hope you enjoy it!