In-depth analysis of IIS 6.0 (14)

Iis

For an IIS server, it is not the name of the Web site that uniquely identifies a Web site, but the ID value of the site. When we create a new Web site in IIS 5.0 and IIS 4.0, the Web server assigns the next available numeric order number to the Web site (that is, the number specified by the Web server for the default site is 1, the next site is 2, then 2, 3, 4, and so on), which is the unique ID of the site. If you want to access a Web site's log file, you must first know the ID of the site, because the log file is saved in the ID number > directory of the \w3svc\< Web site. If more than one Web site is running on a Web server, relying solely on the path name of the log file does not determine which log directory belongs to which Web site. In addition, site IDs are essential whether you are writing a management script or modifying a configuration data file, such as specifying ADSI in the IIS configuration data file (Active Directory service Interface Interface) path, it is often necessary to specify the correct site ID.

However, in IIS 5.0 and IIS 4.0, the ID number of the Web site cannot be found directly from IIS Manager. To do this, the IIS 6.0 manager adds a new identifier column to the site manifest that contains the ID number of the site. However, even if there are only two or three web sites on the IIS 6.0 Web server, and the site ID can be large, such as 387660891 (so the log file path for the site is \w3svc\387660891), it's not surprising that IIS 6.0 no longer specifies the ID of the site in order- It calculates the ID of the site based on the name of the site.

If you have written some scripting aid management, these scripts require the original site ID sequence generation method, you can disable the IIS 6.0 new way of ID generation, the specific steps are: Find HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Inetmgr\parameters registers a subkey, creates a REG_DWORD value incrementalsiteidcreation, sets it to 2 (note that the key does not exist by default).

VII. Asynchronous CGI Processing

IIS 5.0 and IIS 4.0 run CGI (Common Gateway Interface, Common Gateway Interface) processes synchronously, which actually means that only one thread can access a CGI process at a time, so IIS 5.0 and IIS 4.0 The scalability of CGI support is poor. IIS 6.0 can run the CGI process asynchronously, so if a thread calls a CGI application, it does not have to wait for the CGI process to finish processing and return information. Asynchronous CGI improves the performance of the IIS server running a CGI Web application, allowing IIS to run more CGI-based applications that perform mission-critical tasks.

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

It is important to note 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, that is, "adjust memory quotas for a process" and "replace a process level token."

Viii. Bandwidth Limitations

In IIS 5.0 and IIS 4.0, the performance page of the Web Site Properties dialog box allows bandwidth throttling to be enabled, specifying the maximum bandwidth that is allowed for a Web site. However, this feature does not necessarily work because IIS 5.0 and IIS 4.0 cannot directly manipulate the server's network card.

IIS 6.0 is different, and the first time bandwidth throttling is enabled, Windows 2003 automatically installs the QoS Packet Scheduler for the IIS server to invoke. QoS Packet Scheduler enables the server to control the quality of service (that is, QoS), so Windows 2003 temporarily stops all network services during installation. With the QoS Packet Scheduler configured, IIS really has the drivers needed to control Web site bandwidth restrictions-which is good news for ISPs. The minimum bandwidth limit allowed to set is 1024 byte/seconds. Don't forget to check to see if the NIC is on the Windows 2003 Hardware Compatibility List (HCL) because only the latest network adapters support QoS features.