Asynchronous CGI Processing
IIS 5.0 and IIS 4.0 run Common Gateway Interface (CGI) processes synchronously, which essentially means that only one thread can access a CGI process at a time. Thus, IIS 5.0 and IIS 4.0 CGI doesn't scale well. IIS 6.0 runs CGI processes asynchronously, so the thread that invokes a CGI application doesn't just sit and wait for the CGI process to return information. Asynchronous CGI will improve the performance of IIS servers running CGI Web applications and opens the door for more CGI-based applications to perform mission-critical tasks on IIS.
Pass-Through Authentication for Virtual Directories
Microsoft had promised pass-through authentication for remote virtual directories for some time, and the company has finally come through. IIS 5.0 and IIS 4.0 use one username and password to access remote content in a virtual directory that's mapped to a UNC pathname. Funneling all access to a remote server through one user account makes applying granular security on the remote system impossible. In addition, restrictions built into Win2K limit the amount of traffic you can run over one pathname. (For more information about using UNC pathnames with Win2K, see the Microsoft article "IIS Runs Out of Work Items and Causes RPC Failures When Connecting to a Remote UNC Path" at http://support.microsoft.com/?kbid=221790.) IIS 6.0 solves these problems.
IIS 5.0 and IIS 4.0 can also have difficulty receiving file-change notifications from the remote server. Microsoft worked hard on the file-change-notification problem in Windows 2003 and has improved the method IIS 6.0 uses to check for file changes. By default, IIS 6.0 checks for changes every 5 seconds instead of waiting on file-change notifications. This approach improves reliability but might not scale as well as the previous technique, so you can configure the server to use file-change notifications if you prefer. Also, you can now configure virtual directories to pass user credentials through to the remote server. These and other Windows 2003 improvements, such as constrained delegation, not only help with security but with implementing network storage devices and Storage Area Networks (SANs).
Bandwidth Throttling
IIS 5.0 and IIS 4.0's Performance tab in the Properties dialog box lets you enable bandwidth throttling and specify the maximum network use for the Web site. However, this feature doesn't work well because IIS 5.0 and IIS 4.0 can't actually manage the server's NICs. When you first enable bandwidth throttling on an IIS 6.0 Web site, Windows 2003 automatically installs the QoS Packet Scheduler, which interfaces with IIS. The QoS Packet Scheduler enables Quality of Service (QoS) capabilities for the server, so Windows 2003 temporarily stops all network services during the installation. After you configure the QoS Packet Scheduler, IIS has the driver it needs to make bandwidth throttling of Web sites a real possibility for the first time—which is good news for ISPs. The minimum restriction you can set is 1024 bytes per second. You should check that your NIC is on the Windows 2003 Hardware Compatibility List (HCL) because only more recent hardware will support the QoS functions.
To configure the QoS Packet Scheduler, you might first need to create a Group Policy console. Click Start, Run, then type
MMC
and click OK. Click Console, Add/Remove Snap-in, Add. Select Group Policy Object Editor, then click Add, Finish, Close, OK. Now you can expand Local Computer Policy, Computer Configuration, Administrative Templates, Network to display the QoS Packet Scheduler object, as Figure 5, page 73, shows. Installing the QoS Packet Scheduler applies to the entire system some defaults that might affect IIS bandwidth throttling. For example, by default, the QoS Packet Scheduler limits the system to 20 percent of available bandwidth. Consequently, you would need to configure IIS to use less than 20 percent of your bandwidth unless you adjust the QoS Packet Scheduler's Limit reservable bandwidth setting, which Figure 5 shows.
Different Default Settings
IIS 6.0 has some default settings that are different from those in IIS 5.0 and IIS 4.0. For example, the default setting for connection timeouts has been reduced from 900 seconds to 120 seconds. Also, the EnableParentPaths setting is turned off by default. Some of the new settings that might affect server performance are as follows:
- Any request to an extension that isn't mapped in the MimeMap metabase property is rejected.
- By default, all worker processes recycle automatically after 1740 minutes; session information might be lost during this recycle.
- The user context that runs CGI applications must be a member of the IIS_WPG group.
- Collaboration Data Objects for Windows NT Server (CDONTS) isn't installed on Windows 2003. Microsoft encourages developers to use the CDO for Windows 2000 (CDOSYS) object instead.
- An ASP Post is limited to 204,800 bytes by default, and each field is limited to 100KB. IIS 5.0 and IIS 4.0 had no limits.
- Http.sys has a client header limit of 16KB, but you can change the value in the registry.
I'm now at the end of a two-part saga about IIS 6.0, and I still haven't covered all the Web server's features. I didn't mention the redesigned Administrative Web Site that Windows 2003 installs—complete with certificate for SSL—upon request (by default in Windows 2003, Web Edition). I also left out some big-name features such as Passport Authentication and improvements in Digest Authentication. Instead, I reviewed some of the blockbuster features as well as a few of the lesser known capabilities to give you an idea of the depth of the changes in IIS 6.0. In many ways, IIS 6.0 is stealing the Windows 2003 show—and in my opinion, it deserves center stage.
End of Article
Prev. page
1
2
3
[4]
next page -->
