This article discuss brief information about the improvements in IIS 8. Internet Information Services (IIS) 8 includes many new and improved features that make moving to Windows Server 2012 compelling for organizations that rely on Windows Servers as their web server.

Improvement 1: Centralized SSL Certificate Management

With IIS on Windows 8 or Windows Server 2012, you can take advantage of the SSL certificate management console. This is a central management console that is able to install certificates and work with certificates across all IIS 8 web servers.

This includes the ability to more rapidly bring new servers online by being able to import all certificates that are needed. If a certificate needs to be renewed on multiple systems, it can be done through the IIS 8 certificate management console. You no longer have to log onto each system to update the certificate.

Note: Centralized SSL Certificate management is installed as a separate feature. You can install IIS without Centralized SSL Certificate Support. Centralized SSL Certificate Support is in the security section of “Windows Features.”

Improvement 2: Application Initialization

One frustrating problem that many web server admins face is the problem of slow-responding sites as web applications are initializing. A common workaround is to use tools and scripts to “cold start” the applications early in the morning so that the sites are ready to perform: The in-memory cache is loaded, and in some cases the content must be generated, before the IIS server is ready to respond to HTTP requests.

With IIS 8, Application Initialization lets you establish rules for “warming up” sites. For example, you can have larger applications begin the initialization process earlier than smaller applications. You can also configure through application initialization a new splash screen to be displayed in case people find themselves waiting while the application is initializing.

I can see a much better user experience by logging onto a SharePoint site early in the morning and having the first page displayed being a simple “Please wait while this application is being prepared for use” splash screen instead of just a blank page and a spinning circle.

Improvement 3: Dynamic IP Address Restrictions

Restricting access to a website by its IP address is nothing new -- admins have long been able to do that. You can even restrict by a block of IPs in an address range.

The problem that persists is tracking down all of the IP addresses to block. This would usually take a long time of parsing through logs, and even if going through the logs and filtering out the IP addressed were scripted, it is done in a reactive manner.

Instead, using the Dynamic IP Address Restrictions feature in IIS 8 for Windows 8 and Windows Server 2012, you can specify on a per web application level the maximum number of connections that an IP address can create within a certain time frame. And you can also specify the maximum number of attempts that can be made into the IIS 8 server from an IP address within a specific time. Any attempts beyond what is allowed are automatically filtered out, making your web applications and your web server much more resistant to malicious activity.

Dynamic IP Address Restrictions is added as an additional feature of IIS that is not installed by default. To install the feature, open Windows Features, then place a check in the box to select Web Server (IIS) -> Web Server -> Security -> IP and Domain Restrictions. After all that, click Finish.

This article contains brief information about CPU Throttling in the IIS 8. What the differences approach between CPU Throttling in IIS 7 and IIS 8.

CPU Throttling in IIS 7 (and 7.5)

IIS 7 introduced support for CPU Throttling at an Application Pool level.  You could specify a limit of CPU usage and a corresponding action to take when that limit was exceeded.  The two available options were NoAction or KillW3wp.  The names accurately reflect what each option does: Doing nothing in the case of NoAction, or killing the worker process for KillW3wp. 

Let’s take a look at what the KillW3wp option looks like in practice. 

First, I will configure the DefaultAppPool with a limit of 10% CPU.  I have also set the Limit Interval to 1 minute to make it easier to demonstrate how the process is killed and then allowed to restart.

Next, I will apply load to the server using a load generation tool (WCAT, available for download here). 

Here is how things look in the Performance Monitor:

As you can see, the CPU usage is high when the process starts, then the line goes away.  What is happening is that the process is using a high amount of CPU, and after some time IIS realizes that they would use more than their 10% limit within 1 minute (the Limit Interval we configured earlier), so it kills the process for the remainder of the Limit Interval.  The process is prevented from restarting until the Limit Interval expires.  During this time, any user requests will fail with a HTTP 500 error.  After the Limit Interval is reached, the process is allowed to restart, it uses a high amount of CPU again, and it gets killed again.  This cycle will continue to repeat for this application that uses high CPU.

CPU Throttling in IIS 8.0

In IIS 8.0, we’ve worked closely with the Windows Kernel team to deliver a much better CPU throttling experience.  Unlike IIS 7 where the only solution was killing W3WP, in Windows 8 we have two additional throttling options: Throttle and ThrottleUnderLoad.  The Throttle option will always restrict the application to the specified amount of CPU utilization, while the ThrottleUnderLoad option will allow the process to use more than the specified amount of CPU, provided that there is no contention for CPU resources.

The CPU throttling settings are made on the Application Pool.  So if you use the recommended configuration of having each application use its own App Pool, each application will have its own setting for maximum CPU utilization. 

For this example we will use the Throttle option:

As with the IIS 7 scenario, I am using WCAT to apply load to the server.  Here is the CPU graph during the test:

As you can see from the graph, the CPU utilization stays around 10% all the time, instead of climbing higher and having the process be killed like IIS 7. 

Let’s try another example, using PHP this time.  As you know, PHP will use multiple processes for serving requests.  We will see that the CPU utilization stays near 10% even when multiple processes are running.  The sum of CPU usage for all of these processes will be limited to 10%.  Here is a view of Task Manager showing the FastCGI processes running when I put load on the system.  Note how the sum of all 5 processes is 10.4%.

Conclusion

In this post you’ve seen a comparison between the CPU throttling approaches in IIS 7 and IIS 8.  The investments in CPU throttling in IIS 8 provide a much better sandbox that you can use to limit CPU use by an application.