In-depth analysis of IIS 6.0 (five)

Six, website ID
For the IIS server, the only one that identifies a website is not the name of the website, but the ID value of the website. When we create a new website in IIS 5.0 and IIS 4.0, the web server assigns the next available numeric sequence number to the website (ie, the number specified by the web server for the default site is 1, and the next website is 2, then Is 2, 3, 4, etc.), this number is the unique ID of the website. If you want to access the log file of a website, you must first know the ID of the website, because the log file is saved in the \\W3SVC\\<ID ID of the website> directory. If more than one website is running on the web server, relying solely on the path name of the log file cannot determine which log directory belongs to which website. In addition, the site ID is essential whether you are writing a management script or modifying a configuration data file, for example, when specifying the ADSI (Active Directory Service Interface) path in the IIS configuration data file. It is often necessary to specify the correct website ID.

However, in IIS 5.0 and IIS 4.0, the ID number of the website cannot be found directly from IIS Manager. To this end, the IIS 6.0 manager added a new "Identifier" column to the list of sites, the content of which is the ID number of the site. However, even if there are only two or three websites on the IIS 6.0 Web server, the ID of the website may be very large, such as 387660891 (so the log file path of the website is \\W3SVC\\387660891), it is not surprising that IIS 6.0 no longer specifies the website in order. ID - it calculates the ID of the website based on the name of the website.

If you have written some script-assisted management, these scripts require the original website ID order generation method, you can disable the new ID generation method of IIS 6.0. The specific steps are: find HKEY_LOCAL_MACHINE\\SOFTWARE\\ Microsoft\\InetMgr\\Parameters register the subkey, create a REG_DWORD value IncrementalSiteIDCreation, set it to 2 (note that by default, the key does not exist).

VII. Asynchronous CGI Processing

IIS 5.0 and IIS 4.0 run the CGI (Common Gateway Interface) process in a synchronous manner, which means that only one thread can access each time. A CGI process, so IIS 5.0 and IIS 4.0 have poor scalability for CGI support. IIS 6.0 can run CGI processes asynchronously, so if a thread calls a CGI application, it no longer has to wait for the CGI process to finish processing and return information. Asynchronous CGI improves the performance of IIS servers running CGI web applications, enabling IIS to run more CGI-based applications that perform mission-critical tasks.

When the web server receives a URL containing the CGI program name and the parameters required by the program, the CGI program starts executing. If you compile a CGI program into an executable (.exe) file, you must provide a directory containing the program's execute permissions so that the user can run the program. If the CGI program is written in script form (such as a Perl script), it can either provide execute permissions to the directory or provide script permissions. Also, if you want to use script permissions, you must mark the script interpreter as a scripting engine.

It must be noted that by default, the IIS_WPG group does not have permission to start the CGI process. If you create a new account and add it to the IIS_WPG group, you must also grant this account two user rights to start the CGI process, "Adjust the memory quota for the process" and "Replace the process level token."

VIII. Bandwidth Limits

In IIS 5.0 and IIS 4.0, the Performance page of the Web Site Properties dialog allows you to enable the Bandwidth Limit feature, which specifies the maximum bandwidth allowed for a website. However, this feature does not necessarily work because IIS 5.0 and IIS 4.0 cannot directly operate the server's network card.

IIS 6.0 is different. When the bandwidth limit function is enabled for the first time, Windows 2003 automatically installs the QoS packet scheduler for the IIS server to call. The QoS packet scheduler enables the server to control quality of service (ie, QoS), so Windows 2003 will temporarily stop all network services during installation. After configuring the QoS packet scheduler, IIS really has the drivers needed to control the bandwidth limitations of the website - this is definitely good news for ISPs. The minimum bandwidth limit allowed to be set is 1024 Bytes/sec. Don't forget to check if the NIC is in the Windows 2003 Hardware Compatibility List (HCL) because only the latest NICs support QoS.
To configure the QoS Packet Scheduler, you must first create a Group Policy console. Click "Start" → "Run", enter "mmc", and then click "OK". In the console window, select the menu "File" → "Add /Remove Snap-in", click "Add", in the "Add Standalone Snap-in" dialog box, select "Group Policy Object Editor", and then click "Add" "," "Complete", "Close", "OK". Now expand the Local Computer Policy, Computer Configuration, Administrative Templates, and Network in the console to display the QoS Packet Scheduler, as shown in Figure 5. FIG

five

before the bandwidth limit is enabled, using the total number of bytes Check System Monitor "Network Interface" object /s or counter current bandwidth. If you want to compare incoming and outgoing traffic, check the number of bytes sent/sec and the number of bytes received/sec, then compare the value of the Network Interface object with the total bandwidth of the network connection. For a "normal" load, the server should use no more than 50% of its available bandwidth. If the server has a large peak load, keep the normal load below 50% and the remaining bandwidth can be used during peak hours.

Bandwidth restrictions can be for global WWW services (ie for all sites) or for a single site. Setting the maximum bandwidth for a global WWW service does not replace the maximum bandwidth that has been set for a single site on the server. A single site limits bandwidth based on the maximum value that has been set, while global settings limit all other sites that have unlimited bandwidth. In addition, the global WWW service bandwidth limit setting does not affect the FTP site or FTP service.

IX. Changes to Default Settings

In IIS 6.0, the default values ​​for many configuration items are different from those of IIS 5.0 or IIS 4.0. For example, the default connection timeout has been reduced from 900 seconds to 120 seconds. In addition, the EnableParentPaths setting is turned off by default. There are other new setup items that also affect server performance and behavior, including:

(1) If a file type is not mapped in the MimeMap configuration property, all requests for that class file will be rejected.

(2) By default, all worker processes are automatically reclaimed after 1740 minutes, and session information may be lost during reclaim.

(3) The user context for running a CGI application must be a member of the IIS_WPG group.

(4) Windows 2003 does not install Collaboration Data Objects for Windows NT Server (CDONTS). Microsoft recommends that developers switch to the CDO for Windows 2000 (CDOSYS) object.

(5) ASP requests are limited to 204800 bytes by default, and each domain is limited to 100 KB. IIS 5.0 and IIS 4.0 do not have this limitation.

(6) By default, http.sys only accepts requests with a title less than 16 KB.

This article on IIS 6.0 is here to end, although the article is very long, but it is still impossible to do everything, for example, there is no mention of the widespread attention to Passport verification and digest verification improvements, this article The focus is on some of the groundbreaking new features of IIS 6.0 and several features that are rarely mentioned to demonstrate the breadth and depth of IIS 6.0 improvements. In many ways, the hawking of IIS 6.0 has even overshadowed Windows 2003 -- and many believe that IIS 6.0 is indeed qualified to occupy the center of the stage.