IIS 8.0 Beta platform features for web hosters and service providers

Windows Sever 8 beta was released yesterday and I am excited to write about some of the key features for web hosters and service providers.  

Many of the key features evolve around scalability and manageability.   We heard from customers and IIS needed to be better in scaling up as well as scaling out, especially in a multi-tenanted, shared hosting environments.   As you can imagine, the scale challenges are quite different in such environments when you consider the fact that there may be thousands of sites on single instance of IIS.  At the same time, customers have also told us that as we scale up and out, the manageability should remain simple and the cost of managing the sites should not increase.   

We heard you!

  • IIS configuration optimization: As many of you know, in a multi-tenanted environment, IIS recommends creating a separate and dedicated IIS application pool per tenant.   Such configuration ensures process and security isolation between each tenant.   What this also means for IIS configuration system is that it must generate the corresponding isolated configuration file per IIS application pool.   As you can imagine, when you have thousands of tenants, the IIS configuration can be quite busy creating and updating thousands of isolated configuration files. 

  • This behavior leads to two problems: 1) Excessive memory consumption by the IIS configuration system and 2) Performance, as measure by the time it takes to generate and update thousands of isolated configuration files.   IIS 8.0 improves on both of these challenges.   For one, we have optimized our data structure in IIS configuration system so it takes less memory to store the configuration.  But more fundamentally, we changed how IIS configuration generates the isolated configuration files.   The end result is that 1) it takes less memory (We used to have to make multiple copies of the IIS configuration to handle concurrent requests on WS08 RTM and WS08 R2.) and 2) it is much faster in generating the isolated configuration files.   The latter change had another positive impact in that the "first user experience" takes less time with IIS 8.0 because it takes less time to generate the isolated configuration file.

  • SSL scalability and manageability: More and more customers have the need for secure sites.   For example, small and medium sized businesses are using their productivity applications (documentation sharing, email, etc) from online services.   More businesses are selling their products and services online.   And these customers want to keep their brand online by using their own business names (ie. www.mybusinessname.com).   What this means today is that the hosters and service providers must allocate a dedicated public IPv4 address for the secure site.    This is problematic today because 1) there are scale challenges with binding thousands of IP addresses on one Windows instance, 2) additional IP addresses add to the cost and 3) IPv4 addresses are becoming more scarce.

  • IIS 8.0 support Server Name Indication (SNI), which has extended TLS to include the virtual domain name to be passed from the client at the time of "SSL Hello". This effectively allows IIS 8.0 to enable "hostname binding" for SSL sites, which eliminates the need for having a dedicated IPv4 address per SSL site.   In addition, IIS 8.0 has improved how it stores SSL certificates in two ways.   1) It has a new "Web Hosting" certificate store which is designed from the ground-up to be highly scalable.   2) You can now store SSL certificates on a file system.   And because managing files are simpler than managing configuration binding that involves mapping a network end-point to a certificate hash, you can now "import" a SSL certificate simply by copying the SSL certificate.  While making these changes, we have also made it scale up much better on IIS 8.0 and you will see a dramatic difference in secure site density between the previous versions of IIS and IIS 8.0.

  • Sand-boxing resources: IIS 8.0 now has a true CPU throttling of worker processes.   Going back to the isolation model described above, in a multi-tenanted environment, it is our recommendation to create different IIS application pools for each tenants with separate IIS application pool identities.   IIS 8.0 can throttle the CPU consumption per IIS application pool (more specifically per identity user), so the specified limit would be applied to the aggregate CPU consumption of all processes, if there are more than one in the application pool (ie. running PHP application).   Combine this feature with other resource management features in pervious versions of IIS, you can now define a resource sand-box based on CPU, memory, network bandwidth and disk storage.  

For more information on above features and others, please refer to the IIS 8.0 documents on iis.net and technet.

And please take IIS 8.0 beta for a spin and we would love to hear your thoughts.

1 Comment

  • You keep mentioning that you recommend that each site have its own app pool, how much ram do you expect us to put in a web server? Each pool takes up a process that eats ram. How much ram does a single pool with one site use?

Comments have been disabled for this content.