Inside IIS 6by Mitch Tulloch, author of Windows Server 2003 in a Nutshell
Internet Information Services (IIS) is not only a popular platform for hosting web sites, it's also a required component for a number of Windows server system products, including Content Management Server, Exchange Server, and Systems Management Server. Because these products rely on IIS for many of their core functions, understanding how IIS works is essential if you need to deploy, administer, or troubleshoot such products.
With the release of Windows Server 2003, Microsoft has made significant changes to how IIS works compared with earlier versions. This article is designed to quickly get you up-to-speed regarding the new architecture of IIS 6 and how it differs from IIS 5 (Windows 2000) and IIS 4 (Windows NT) in three key areas: application isolation, HTTP request handling, and the XML metabase. For a more detailed examination of IIS 6 architecture, see chapter 2 of my book IIS 6 Administration.
IIS 4 first introduced the idea of an out-of-process application, that is, ISAPI or ASP code that runs in a separate memory space from inetinfo.exe, the core web server process associated with the IISAdmin and WWW services. The advantage of using out-of-process applications was that they could be stopped and started independently from one another, and if one of them crashed it didn't bring down the entire web server.
There were disadvantages, however -- out-of-process applications couldn't communicate with each other, ran slowly, and consumed huge amounts of memory. As a result, running applications out-of-process was usually used only during the development phase for troubleshooting unstable applications, and once an application was debugged it was moved in-process with inetinfo.exe. And then if any bugs were still left, the server crashed and had to be manually restarted.
IIS 5 added a new type of application protection called pooled process, which let you run several applications together in a COM+ host process called dllhost.exe that was separate from the core inetinfo.exe process where the WWW service resides. The advantages of running applications as pooled process included improved performance and better resource usage over isolated processes. Plus, if one application in the pool died it would bring down only the other pooled applications and not the entire server.
Additionally, IIS 5 could automatically restart pooled applications if they failed, reducing the number of manual reboots required on your machines. IIS 5 ran all applications as pooled processes by default, but they could also be moved out-of-process for troubleshooting purposes or in-process for top performance. One limitation, however, was that IIS 5 only had one pool for lumping applications together.
The architecture of IIS has been completely revamped in IIS 6 (see Figure 1 for a comparison of architectures for different IIS versions). There is now only one kind of application isolation available: application pools. These pools are similar to pooled processes in IIS 5, but now you can create as many pools as you like and group your applications accordingly.
These pools are completely isolated from each other and thus combine the benefits of out-of-process and pooled-process as in IIS 5. And in IIS 6 you can no longer run web-application code in process with inetinfo.exe, though this process still encapsulates all FTP, SMTP, or NNTP sites running on the server. Instead, a new service called the Web Administration Service (WAS) replaces IISAdmin as the user-mode component of the WWW service.
Figure 1. Comparison of architectures for different versions of IIS.
This new architecture for IIS 6 is named "worker process isolation mode," because any user-developed application code must now run within a worker process (w3wp.exe) as its host process instead of the dllhost.exe process used by IIS 5. There are several advantages of this new architecture. For example, one worker process can service several applications within a pool, providing isolation between applications running within other pools. One pool can also be serviced by several worker processes in a configuration known as a web garden that increases availability on a single machine the way web farms do using multiple machines.
The WAS also monitors the health of worker processes and can terminate blocked processes and spin up new ones to take their place, further improving performance. And on a multiprocessor machine a new feature called processor affinity lets you assign individual worker processes to specific CPUs to fine-tune performance.
But what happens if you move your existing IIS 5 applications to IIS 6 and they have trouble running on the new architecture? Simply switch your server from worker process isolation mode to IIS 5 isolation mode (see Figure 2) and suddenly there are no more application pools, worker processes, WAS, or processor affinity -- you've got IIS 5 instead. Or at least something that's similar to it in architecture, which should keep your legacy apps running until you can recode them to take advantage of the new features of worker process isolation mode.
Figure 2. Switching from worker process isolation mode to IIS 5 isolation mode.
In previous versions of IIS the core inetinfo.exe process was hooked into the TCP/IP stack to pull out incoming HTTP requests and pass them to the WWW service (w3svc.dll) or a dllhost.exe helper process as appropriate. In IIS 6 however, the WWW service has now been moved out of inetinfo.exe into the WAS, and inetinfo.exe no longer fields HTTP requests from the stack. Instead, this activity has now been taken over by the new kernel mode HTTP listener (http.sys), which resides within the TCP/IP stack, listening for incoming HTTP requests and routing them to the appropriate worker process.
This architectural change (both within IIS and the networking subsystem) has several significant results. Responsiveness is improved because http.sys can queue HTTP requests if the worker process that services them is blocked or busy. Performance is improved because http.sys is a kernel-mode process, in comparison with inetinfo.exe, which was a pageable user-mode process. And reliability is improved because http.sys cannot encapsulate any user-developed code the way inetinfo.exe could in IIS 5. Http.sys also caches HTTP responses for both static and dynamic content, generates IIS log entries, and manages establishing and tearing down TCP sessions for HTTP communications.
Note that while http.sys means big performance gains for applications running on IIS, it can cause compatibility problems for third-party HTTP applications you have running on your server. Fortunately there's a workaround using a command-line tool called httpcfg.exe, found in the \Support\Tools folder on your product CD. See article 813368 in Microsoft's Knowledge Base for information on how to use it.
Finally, a major change in IIS 6 regards the metabase, the memory-resident database used in place of the Registry for storing most IIS configuration settings. The biggest change here is from the proprietary binary format used in the IIS 5 metabase to a text-based XML format. This change makes it easier to edit and customize the metabase to meet your needs.
In fact, IIS 6 now lets you edit the metabase even while IIS services are running on your machine, something you couldn't do in earlier versions and which helps avoid downtime for your sites. (Note that you have to enable this first, see Figure 3). IIS 6 also makes it easier to back up and restore the metabase, even to a different machine, opening the way for you to create a master IIS machine, clone its settings, and copy them to other machines. The new metabase history feature even generates backups automatically whenever changes are made to the metabase. And a new WMI provider for IIS lets you programmatically edit the metabase, allowing you to script changes and apply them to multiple sites much faster than you could do using IIS Manager, the GUI console for managing IIS.
Figure 3. Enabling the new metabase edit-while-running feature on IIS 6.
Does this mean you'll have to learn XML in order to get the most out of IIS? Maybe, but the format for the metabase is simple to understand and as long as you make backups before you begin, go ahead and start messing around!
Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.
Return to WindowsDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.