What was Microsoft.com's experience in reliability in moving from Windows 2000 Server to Windows Server 2003? Microsoft Developer Network (MSDN) had a 100 percent increase in uptime, as Table 1, page 42, shows. Some of the OS restarts were required reboots for hotfixes and service packs, which Microsoft is working to significantly reduce.
So how did these improvements in Microsoft.com reliability come about? Some cool features in the Windows 2003 server family and IIS 6.0 make such improvements possible.
Isolation of WWW Service Administration and Monitoring
One of the biggest changes that directly affects reliability involves how IIS 6.0 works internally. To have a basis for comparison, let's take a quick look at the IIS 5.0 architecture. In IIS 5.0, the primary process that runs the core IIS functions is inetinfo.exe. Inetinfo also hosts Web applications that you set to run in Low (In Process) Application Protection in the Microsoft Management Console (MMC) Internet Information Services console. You can also run Web applications "out of process" by setting Application Protection to Medium (Pooled) or High (Isolated), in which case they run in a process named dllhost.exe. Inetinfo has other significant duties such as routing incoming requests from Winsock to the proper out-of-process Web applications and hosting the IIS Admin Service, which communicates with the metabase (i.e., the configuration store of settings for IIS Web sites and directories). As a result, tasks related to the configuration and internal administration of the Web server run in the same process as Web applications. As a result, a poorly written application can throw an exception (i.e., crash) or otherwise halt Inetinfo and bring the entire Web server, including the out-of-process applications, to a halt.
In IIS 6.0, the WWW Service Administration and Monitoring component runs in a separate process from Web applications so that a crashed or hung Web application can't cause WWW Service Administration and Monitoring to fail. This separation lets WWW Service Administration and Monitoring monitor the Web server and keep it running—WWW Service Administration and Monitoring can even restart applications that fail to respond to "Are you live?" requests from the component.
Application Pools
IIS 6.0 Web applications run in a worker process called w3wp.exe, the replacement for IIS 5.0's Dllhost (and IIS 4.0's wam.exe). However, in IIS 6.0, you can give a worker process a name and manage it as an item called an application pool. You can easily assign a Web site, directory, or virtual directory to any application pool by using that item's Properties dialog box, as Figure 1 shows.
Keep in mind that each application pool is isolated from the other pools so that if one pool fails or is recycled, only the applications in that pool are affected; other application pools keep delivering content. This feature is perhaps the heart of IIS 6.0's reliability improvements. You can organize your applications in pools that best suit your requirements. For example, you might group applications that run reliably into one pool and isolate unreliable or untrusted applications into separate pools to insulate the reliable applications from the untrusted applications' wayward behavior.
WWW Service Administration and Monitoring automatically checks that an application pool is responsive every 30 seconds (by default) or at an interval that you can define on the Health tab of the application pool's Properties dialog box. If the pool fails to respond, WWW Service Administration and Monitoring recycles, or restarts, the pool without administrator action, which greatly improves reliability. In addition, you can use the settings on the Recycling tab, which Figure 2 shows, to configure when that pool will recycle (i.e., stop and start). For example, by default, application pools recycle every 1740 minutes (i.e., 29 hours). This value doesn't make any sense to me as a default, so I set the recycling to occur at a specific time of day, say 3:00 a.m. local time. Scheduled recycling can be useful for applications that need to be periodically reset.
The Recycling tab also lets you monitor a worker process's memory consumption and recycle the application when it exceeds a certain threshold. The ability to automatically recycle applications that are overconsuming resources will help a great many IIS servers that must deliver applications that inexplicably consume too much memory over time. For more information about IIS 6.0's recycling process, see the sidebar "How Recycling Works."
When you configure recycling for your application pools, you will likely want to set IIS 6.0 to record recycling events in the Event Viewer when they occur. By default, only memory- and time-based recycle events are recorded. Look in the IIS 6.0 Help files for the LogEventOnRecycle metabase property. This property is a bitmask value in which each bit turns recording of a specific event on or off. You can use the following command to turn on recording of all the events:
cscript SystemDrive\InetpubAdminScripts\adsutil.vbs
set W3SVC/AppPools/
LogEventOnRecycle
Register
