Each new version of Microsoft Internet Information Services is a little like a new installment in a novel series where each book comes several years apart, but proves to be well worth waiting for.
IIS 8, which comes with Windows Server 2012, has new features aimed at those who are putting together large-scale Web hosts. But one of the nice side effects of those big-scale features is how they dial down to smaller hosts and individual servers as well.
CPU throttling: the next generation
IIS 7 has a CPU throttling function that prevents unruly sites from gobbling up too much CPU. Unfortunately, it has an all-or-nothing flavor to it which makes it less useful than it ought to be.
First, when you have throttling set for a site, the only form of throttling available is to kill the site process entirely for a certain length of time. You can set the CPU threshold and kill length, but it means the site is completely disabled for whatever that length of time is. There is no native way to configure IIS to have a site only use 90% of CPU for processor X (or all processors) at any time.
Second, IIS 7’s CPU throttling is bound to a given application pool. This isn’t so bad if you have a separate pool for each website, and that by itself isn’t a bad idea if you have the CPU cores to throw at such a proposition. (Even if you only have one core, it’s still not a bad idea for low-CPU sites.) But if you have multiple sites that share the same application pool, they all go offline if CPU throttling kicks in for only one of those sites.
IIS 8’s solution to all this is to add two new actions to the way CPU throttling works: Throttle and Throttle under load. Throttle caps CPU for a given worker process, and any child processes spawned by that worker as well. Throttle under load allows a site to use as much CPU as is available, but will throttle that process back if it starts competing for CPU with other processes.
This allows throttling to be done without killing the process wholesale, and adds that much more flexibility in multi-tenancy environments. You can run that many more sites side-by-side, with or without setting explicit processor affinities for their worker processes, and not have them stomp all over each other.
Another refinement is the Application Initialization Module, which allows a site to accept requests for pages and respond with a friendly message while the site code itself is still being spun up. This feature can keep people from pounding on their browser’s refresh button when a change to a library forces a recompile.
SSL improvements
I’ve never liked the way IIS has handled SSL. “Clunky” and “cumbersome” are two of the less vitriolic adjectives I’ve used to describe the whole process of adding and managing SSL certificates to IIS. Thankfully, IIS 8 has three major new improvements to its handling of SSL.
Centralized certificate management. IIS 7 forces you to import each certificate into each instance of IIS, which is a headache if you’re managing a whole farm’s worth of servers. IIS 8 lets you create a Central Certificate Store, or CCS. This allows all the certificates needed across your farm to be placed in a single location. The name of the certificate file can be used to automatically map and bind the certificate to the domain in question, and multiple-domain certificates are also supported through this scheme (you just make multiple copies of the certificate and rename it appropriately).
Server Name Indication support (for using SSI with host headers). Not long ago I discovered for myself, the very hard and painful way, how difficult it is to have SSI on a server where multiple sites share a single IP address and use host headers. A new technology named Server Name Indication allows SSI to be used on sites that can only be reached via host headers, but it requires both a server and a client that can support it. IIS 8 fixes the “server” end of the equation, and most recent browsers provide support (with one glaring exception being any version of IE on Windows XP).
Scalability. Thanks to improvements in how certificates are loaded and managed, SSL-enabled sites now scale far more efficiently, and you can support many more of them on the same hardware (up to thousands). On the same note, IIS’s handling of configuration files (*.config) have been reworked for the same kind of scale.
FTP Logon Restrictions and Dynamic IP Restrictions
I have a theory: because Microsoft has had such a brutal trial by fire as far as security goes, they’re being forced to constantly think about new and more proactive ways to make their server products secure. To that end, two new security features in IIS help provide short- and long-term blocking of IP addresses for both the HTTP and FTP services. Granted, nobody uses IP blocking as any kind of permanent solution to a security issue, but such a feature is still useful to have as a stopgap against attacks.
Dynamic IP restrictions allow you to configure IIS to block access from IP addresses that break rules about how many requests they attempt to make in a given period of time, or when using more than a certain number of concurrent requests. What’s more, the denial of the connection can be done via more than just returning the standard 403.6 Forbidden error IIS 7 would use in such circumstances. The server can be set to return a 401 (Unauthorized), 403 (Forbidden), 404 (Not Found), or simply terminate the HTTP connection without even returning an error. A special proxy mode also allows inspection of the HTTP headers for the X-Forwarded-For header, as a way to find the source of traffic that may be forwarded through a proxy.
FTP logon attempt restrictions allow you to lock out people if they try to make multiple failed attempts to log into the FTP server. The lockout period is normally 30 seconds, but it can be set to anything you want, and the number of attempts is also flexible. This works a little like the tarpitting/graylisting systems used to keep spammers from overwhelming mail servers: only those who are clearly trying to barge their way in get stalled.
Multicore scaling and NUMA awareness
Most of the IIS servers I’ve dealt with have been minimal affairs, with a handful of low-traffic sites that share space on a single- or dual-core server. I know full well, though, that some IIS setups are sprawling affairs: dozens of cores or sockets, many gigabytes of RAM, and all sorts of other high-end hardware features to make sysadmins cry with joy.
IIS hasn’t always made the best possible use of some of those high-end features. Multiple cores, for instance: according to Microsoft, one of the problems of adding more cores is that after a while it actually hurts performance in some setups “because the cost of memory synchronization out-weighs the benefits of additional cores.” In other words, the processing power of those extra cores is offset by the overhead required to keep memory synchronized with a given core.
IIS 8 has a new feature to compensate for this problem: Non-Uniform Memory Architecture (NUMA) awareness. NUMA servers dedicate specific areas of physical memory to specific processors, with crossbar or bus systems to allow processors to talk to the memory that’s not “local” to that processor. Both operating systems and software have to be written to take proper advantage of NUMA, but the benefits include being able to do things like hot-swap failing memory modules and, most importantly, not succumb to the ways poor memory architecture can kill performance.
IIS 8 supports NUMA and multicore scaling in several different ways:
Workload partitioning. IIS can pool worker processes by creating the same number of worker processes as there are NUMA nodes, so each process runs on its own node — essentially, the “Web garden” approach. You can also have IIS set up multiple worker processes and have the workloads distributed across each node automatically.
Node optimization. The default method IIS uses for picking a node when a given worker process starts is to choose the one that has the most available memory, since that’s typically going to yield the best results. IIS can also default to letting Windows Server itself make that decision, which is useful if you have other NUMA-aware server-level apps running on the same hardware.
Thread affinity. IIS can use one of two methods to figure out how to pair threads with NUMA nodes. The “soft affinity” method allows a given thread to be switched to another NUMA node if that node has more CPU to spare. The “hard affinity” method picks a node for a thread and leaves it there.
WebSockets
This long-in-development technology is supposed to fix one of the major limitations of HTTP since its inception: you can’t really keep a connection open indefinitely between the client and the server for real-time full-duplex communication. IIS 8 adds WebSocket support, although it has to be installed as part of the “Application Development” package of add-ons when setting up IIS 8 (along with, say, ASP.NET 4.5)
Conclusion
While many of the new IIS 8 features are clearly designed for those hosting whole server farms or massive multi-core setups, there’s a lot here to appeal to folks on other tiers as well. I know that if I ever upgrade the server I’m using to a multicore model—even just 2-4 cores—I’ll have a whole raft of new IIS features I can use to make it all the more worth my investment.
Windows Management and Scripting 