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 particular 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 terrible if you have a separate pool for each website, and that by itself isn't a terrible thought if you have the CPU cores to throw at such a proposition. (Even if you only have one core, it's still not a terrible thought 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 outcome 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 candid processor affinities for their worker processes, and not have them stomp all over each other.
Another minor change is the Application Initialization Module, which allows a site to acknowledge requests for pages and respond with a friendly message while the site code itself is still being spun up. This feature can keep public 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 give reasons for the total 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 total farm's worth of servers. IIS 8 lets you initiation a Central Certificate Store, or CCS. This allows all the certificates needed across your farm to be placed in a single place. 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 owing to this scheme (you just make multiple copies of the certificate and rename it appropriately).
Server Name Indication help (for using SSI with host headers). Not long ago I learned for myself, the very hard and painful way, how hard 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 help it. IIS 8 fixes the “server” end of the equation, and most recent browsers provide help (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 help 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 reckon in this area new and more proactive ways to make their server products secure. To that end, two new security features in IIS help provide small- 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 check access from IP addresses that break rules in this area how many requests they attempt to make in a given period of time, or when using more than a particular 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 Establish), or austerely 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 owing to a proxy.
FTP logon attempt restrictions allow you to lock out public 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 small like the tarpitting/graylisting systems used to keep spammers from overwhelming mail servers: only those who are visibly 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, even if, 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 weep 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 really hurts performance in some setups “because the cost of memory synchronization out-weighs the repayment of additional cores.” In other words, the processing potential of those extra cores is offset by the overhead vital 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 system 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 repayment include being able to do things like hot-swap failing memory modules and, most importantly, not give in to the ways poor memory architecture can kill performance.
IIS 8 supports NUMA and multicore scaling in several uncommon ways:
Workload partitioning. IIS can pool worker processes by making 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 let Windows Server itself make that choice, 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 interaction. IIS 8 adds WebSocket help, 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 visibly designed for those hosting total server farms or massive multi-core setups, there's a lot here to fascinate to those 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 total raft of new IIS features I can use to make it all the more worth my investment.