modifying MetaBase.xml files to promote IIS performance

The MetaBase.xml file is the setup file for IIS, and each Web site has IIS settings under this, so you should back up the file before you modify the file. This file is in C:\WINDOWS\system32\inetsrv\Metabase.xml, and the previous IIS-enabled static compression can also be set under files, or it can be set in the graphical interface of IIS.

To optimize the performance of IIS to the right remedy, for different sites have different optimization methods, in the analysis of the characteristics of your site, and then the parameters in the MetaBase.xml file to adjust, improve the performance of IIS.

AppAllowDebugging

Role: Specifies whether Active server Page (ASP) debugging is enabled on the server. When this property is enabled, the IIS application thread is serialized, and for each application, only one thread is allowed to execute at a time. Serializing a thread can adversely affect WEB server performance. It is recommended that you set this property to False on all product servers.

Note: When server-side debugging is allowed, the IIS application thread is serialized: For each application, only one thread is allowed to run at the same time. This can affect server performance at busy sites.

AspBufferingOn

Function: This property specifies whether the output of an ASP application requires buffering. If this value is set to True, all output from the application is concentrated in the buffer before the buffer is flushed to the client browser. With buffering enabled, the ASP application must process all ASP scripts before the client browser receives any output. As a result, buffering-enabled applications appear to be slower than those that do not have buffering enabled, although caching-enabled scripts have less total time. So, if buffering is enabled, consider using the flush method of the response object built into the ASP to pass the content to the user while the script is being processed.

Note If you set this property to False, the output of the ASP script is output to the client browser once it is available. If buffering is not enabled, all methods that modify an existing HTTP header or generate a new header must be executed before the body of the content is passed to the client browser. This restriction is not necessary if buffering is enabled. It is recommended that you set this property to true on all product servers.

AspQueueConnectionTestTime

Role: IIS places all ASP requests in the queue. If the request waits in the queue longer than the time specified by the AspQueueConnectionTestTime property (in seconds), the ASP checks to determine whether the client is still connected before executing the request. If the client is disconnected, the request is not processed and the request is removed from the queue.

Note: In most cases, users do not wait for more than a few seconds to process an ASP page. Although the maximum wait time varies depending on the user, the maximum acceptable time is approximately 10 seconds. You can use the AspQueueConnectionTestTime property to ensure that IIS does not waste time processing requests that have been discarded by the user. This property is useful for making an ASP work efficiently when the ASP is about to begin processing the script's state. Once the script is running, the application should continue to use the IsClientConnected method of the ASP built-in Response object to check the client connection at the right time.

AspRequestQueueMax

Function: This property specifies the maximum number of concurrent ASP requests that are allowed to enter the queue. When a queue fills up, any client browser that attempts to request an ASP file will receive an HTTP 500 "Server Too Busy" error.

Note: Setting this property at the IIsWebService level can be applied to all processes and common out-of-process application items at all levels. In-process and shared out-of-process applications ignore configuration database settings at the IIsWebServer level and lower levels. However, if the item is an out-of-process isolation application, the settings at the IIsWebServer level or lower level are used.

AspScriptEngineCacheMax

Role: This property specifies the maximum number of script engines that the ASP page will keep cached in memory. Adjust default values based on the type of content in your application. (default does not include currently running script engine) If you have thousands of different pages, you will experience some of the benefits of increasing the cache size: Most frequently requested pages can be easily accessed. The benefit of scripting engine caching means that you can not recompile the template to byte code.

AspScriptFileCacheSize

Function: This property specifies the number of precompiled script files to cache. If set to 0, no script files are cached. If set to 4294967295, all script files are cached. This property is used to adjust performance, depending on the amount of available memory and script file transfers.

Note: The configuration database represents infinity as a DWORD value 4294967295 (0xFFFFFFFF), and VBScript represents infinity as a hexadecimal value &hffffffff. Previous versions of IIS represented Infinity as-1.

AspSessionMax

Function: property specifies the maximum number of concurrent sessions allowed by IIS. When this limit is reached, if the client attempts to establish a new connection with IIS, the client receives an error message (HTTP 500 "server is too Busy").

Note: The configuration database represents infinity as a DWORD value 4294967295 (0xFFFFFFFF), and VBScript represents infinity as a hexadecimal value &hffffffff. Previous versions of IIS represented Infinity as-1. The ASP needs to exceed a certain amount of memory required to keep all sessions. Although you can use AspSessionMax to limit this memory, it is usually more appropriate to use the AspSessionTimeout property to manage the lifetime of Session objects in IIS, and the client browser will be rejected once the limit is reached.