Performance Settings

You can adjust both IIS metabase properties and registry settings to tune the performance of your Web server. If you do plan to make changes to the registry, do not use a registry editor unless you have no alternative. Registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require you to reinstall Windows 2000. The same can be said for making changes to the IIS metabase with the adsutil administrative utility (found in the Inetpub\AdminScripts directory). To configure or customize Windows 2000 and IIS 5.0, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

Metabase Settings

This list includes the most important metabase settings for tuning your Web servers. These can be retrieved and changed using the ADSI interfaces. Most of these settings will not take effect until the Web service is restarted. Refer to the section on the IISReset utility for more information.

AppAllowDebugging—This property specifies whether ASP debugging is enabled on the server. If this is the case, IIS application threads will be serialized, meaning that only one thread at a time will be allowed to execute for each application. This will adversely affect Web server performance. You should set this property to FALSE (the default) on all production servers.

AspAllowSessionState—The default value is TRUE. Turning this to FALSE can lead to better performance. Once changed, developers will have to explicitly override this setting in pages that need to make use of the Session object. To change the default setting for a single page, developers can use <% @EnableSessionState=False %> at the top of the page. Be sure to notify developers if you change this setting.

AspBufferingOn—The default value is TRUE, after a clean install of Windows 2000. If the machine was upgraded from NT 4, you may need to turn it on. This property's default behavior allows all output from an application to be collected in the ASP output buffer before the buffer is flushed to the client browser. If this property is set to FALSE, output from ASP scripts will be written to the client browser as it becomes available. You should make sure this property is set to TRUE on all production Web servers. For more details, see the "Tuning and Troubleshooting Suggestions" section of this appendix.

AspThreadGateEnabled (default value is FALSE) and AspProcessorThreadMax (default value is 25)—Thread gating is enabled when you set AspThreadGateEnabled to TRUE, and IIS 5.0 dynamically changes the number of worker threads in response to changing workloads. The maximum number of worker threads that IIS will allow per ASP process is AspProcessorThreadMax multiplied by the number of processors on your server. Reduce this value and monitor performance. If performance degrades, bring the AspProcessorThreadMax value back up. For more information, see the AspThreadGateEnabled property description in this appendix.

AspRequestQueueMax—The default limit for requests in the queue has been increased to 3,000 for IIS 5.0. The effectiveness of this setting depends on the behavior of the application. If the request's execution time is very short and the time in the queue will be short, it is reasonable to increase this limit.

AspQueueConnectionTestTime—This is a new setting for IIS 5.0 and aids significantly in the performance of Web applications. In IIS 4.0, execution of a request was unconditionally started when it was removed from the queue. In IIS 5.0, if a request has been in the queue longer than the queue connection test time, the server checks to see that the client is still connected before beginning execution. This feature handles the problem of impatient users filling up the request queue with numerous attempts at the same page. The default value is three seconds. Base your decision to change this value on the type of Web application your server is running. Long-running ASP pages can also make use of the Response.IsClientConnected method to see if the client is still waiting for the rest of the page. Long-running pages should make judicious use of Response.Flush to ensure that users perceive that the page is still alive and doing productive work. For more information about the Response object methods, see the IIS 5.0 online documentation.

AspSessionMax and AspSessionTimeout—The default behavior is to limit the length of single sessions to 20 minutes rather than to limit the number of concurrent sessions. For applications that take advantage of sessions, it may be prudent to reduce the Session Timeout to reduce the overhead required of the server, but if concurrent sessions increase to unwieldy proportions, it may be necessary to include a Session Maximum.

AspScriptEngineCacheMax—The new default for the maximum number of script engines to cache in memory is 125. This does not include currently running script engines. Adjust this according to the type of content in the application. If there are thousands of unique pages, there is probably some gain associated with increasing the cache size so that the most frequently requested pages can be readily accessed. A hit in the script engine cache means that you can avoid recompiling the template into byte code.

Before you set this metabase property, you should understand how ASP uses the ASP Script Engine Cache and the ASP Template Cache. For further discussion, see the "ASP Caching" section.

AspScriptFileCacheSize—This property specifies the number of precompiled script files to store in the ASP Template Cache. If 0, no script files will be cached. If -1, all script files requested will be cached. The default value is 250. Increase this value if you have many different ASP pages. Do not set the value of this property to 0. This turns off all ASP caching and will severely impair your server's performance.

AspTrackThreadingModel—This metabase property specifies whether IIS will check the threading model of any components that your application instantiates. If this metabase property is left set to its default value (FALSE), the overhead incurred by ASP's threading model tracking is avoided, and you might see performance improvements in your ASP application. However, if this property is set to FALSE, any components that you create that you plan on giving Application scope must be agile: either marked as Both-threaded and aggregate the free-threaded marshaller or marked as ThreadingModel=Neutral. If an Application-scoped component is not agile, ASP will generate an error when you try to instantiate the component. In addition, if this property is FALSE, any objects that lack OnStartPage or OnEndPage methods and are instantiated in your ASP application will be released earlier than they would otherwise. This should improve your application's scalability. The default value for this property in IIS 4.0 was TRUE. It is not recommended that you enable it in IIS 5.0. For more information, see the IIS 5.0 online documentation.

CacheISAPI—This property indicates whether ISAPI extensions are cached in memory after use. If the value of this property is TRUE, the DLL file will remain in the cache until the server is stopped. If the value is FALSE, ISAPI extensions are unloaded from memory once the extension DLL is no longer in use. ISAPI extensions are cached or not cached based on the value of this property at the time they were loaded into memory for use. Thus, if this property is changed after an extension has been loaded and cached, the change will have no effect on that extension.

Setting this property to FALSE can be helpful for debugging, but make sure that it is set to TRUE on all production Web servers. Reloading an ISAPI extension DLL file for every request is very expensive and will degrade performance. ASP.dll is itself an ISAPI extension, so disabling this property will also degrade ASP performance.

ConnectionTimeout—This property specifies the time in seconds the server will wait before disconnecting an inactive connection. The default value is 900 seconds (15 minutes). Since open connections can degrade performance, consider lowering this value and monitoring your servers to see what impact this change makes.

MaxEndpointConnections—This property specifies the maximum number of "listen" sockets that will be aggregated on a network endpoint. For example, if this value is set to 15, a maximum of 15 total connections can be made to a single port, even if more than one domain is bound to the port. The lower of this property value and the value of the ServerListenBackLog property determines the number of sockets pooled on your server. Set this to a high number and monitor performance. The default value is 100.

ServerListenBackLog—This property specifies the number of outstanding sockets that can be queued. The lower of this property value and the value of the MaxEndpointConnections property determines the number of sockets pooled on your server. Set this to a high number and monitor performance. The default value is based on the AcceptEx operating system parameter and on the server size specified in the ServerSize metabase property. If ServerSize is set to 0, the default for this property is 5. If ServerSize is 1, the default is 40. If ServerSize is 2, the default is 100. Valid values for this property range from 5 to 1000.

ServerSize—This property specifies the general size of the server, in terms of number of client requests processed per day. A value of 0 indicates a small Web site that would expect to receive fewer than 10,000 requests per day, a value of 1 indicates a medium site handling between 10,000 and 100,000 requests a day, and a value of 2 designates a large site processing more than 100,000 requests a day. The default value is 1 (medium). To maximize the number of requests your server can handle, set this property to 2. You can adjust this setting using the UI. Open your site's property sheet, select the Performance tab, and adjust the Performance tuning slider to More than 100,000.

Registry Settings

This section lists the registry settings that you should be most concerned with when you tune your Web server. Included is the registry path for settings that reside in the same location, along with the name, range, default value and a description of what each setting does. You will have to restart Web services on your server for new Inetinfo settings to go into effect. For more information, see the "IISReset Utility" section.

Registry Path:

 HKEY_LOCAL_MACHINE\SYSTEM  \CurrentControlSet   \Services    \Inetinfo     \Parameters  


DisableMemoryCache REG_DWORD

Range: 0, 1

Default: 0

Make sure that this parameter is set to 0 on all production servers. If this parameter is set to 1, static file caching will be disabled. While this may be useful during debugging, disabling caching can severely compromise production server performance. This parameter cannot be configured by using the IIS snap-in.


MaxCachedFileSize REG_DWORD

Range: 0 to Unlimited (measured in bytes)

Default: 262,144 bytes (256KB) if value is not in registry.

This parameter determines the maximum size of a file that can be placed in the cache. IIS will not cache files that are larger than MaxCachedFileSize bytes. If you are running large dedicated Web servers, you may want to add this value to the registry to increase the file size that the cache can hold.


MemCacheSize REG_DWORD

Range: 0 MB to Total MB of Available RAM

Default: 50% of available memory if value is not in registry

This parameter specifies the maximum amount of memory that IIS will use for its file cache. If IIS does not need this much memory, it will be left for other applications to use. If this value is not in the registry, IIS will use no more than half of the available memory on the Web server (which is dynamically calculated every 60 seconds). If you are running large dedicated Web servers, you may want to add this value to the registry and increase the amount of memory that IIS can use. You must specify this size in MB when you add this object to the registry.


ObjectCacheTTL REG_DWORD

Range: 0 to Unlimited

Default: 30 seconds

This parameter controls the Time To Live (TTL) setting of the static file cache, which defines the length of time that objects, including files, are held in cache memory. If an object in the memory cache has not been referenced for the defined period, that object will be phased out of the cache. By default, this value is not included in the registry. If you wish to change it, you must add it manually. If system memory is limited, or the server's contents are dynamic, you can use a lower TTL to prevent system memory from being used to cache a large number of volatile objects. Setting the value to 0xFFFFFFFF disables the object-cache scavenger and allows cached objects to remain in the cache until they are overwritten. Disabling the cache scavenger is useful if your server has ample system memory and your data is relatively static. Other sites may prefer the compromise of raising this value to several minutes.

NOTE


Due to current limitations in the Microsoft Server Message Block (SMB) protocol, IIS can support only a limited number of shared directories. If you are running more than 50 shared directories, set this limit to a low range (for example, a maximum of three minutes) to ensure that you receive file change notifications when content is updated.


PoolThreadLimit REG_DWORD

Range: 0 to Unlimited

Default: 2 * # MB

This parameter specifies the maximum number of I/O worker threads that can be created in the Inetinfo process, which limits the number of simultaneous connections. IIS sets PoolThreadLimit to 2 * the number of megabytes of RAM present in the machine. If this value is larger than 256, it will be clamped to 256. If a value is present in the registry, it overrides IIS's calculation. Each pool thread watches for a network request and processes it, either by sending back a static file or by passing the request to an ISAPI extension DLL (such as ASP) or to a CGI. If the ISAPI extension processes a request synchronously and it takes a long time to process requests, then it will tie up the worker thread, leaving IIS with fewer worker threads to process other requests. For this reason, well-written ISAPI extensions, such as ASP, implement their own thread pools, place requests in a queue, and process them asynchronously with their own threads. In general, if you find that the default limit of 256 threads is inadequate, you probably have a poorly written ISAPI extension tying up IIS worker threads. 256 is a lot of threads to have active simultaneously and will incur significant overhead in synchronization and context switching.

PoolThreadLimit is a hard limit that includes all IIS worker threads, including the HTTP, FTP, NNTP, and SMTP services. PoolThreadLimit will always be greater than or equal to MaxPoolThreads.

The ASP thread pool is a separate set of threads. Its size is controlled by the AspProcessorThreadMax metabase setting. The largest possible number of outstanding ASP requests is the sum of AspRequestQueueMax and AspProcessorThreadMax.


MaxPoolThreads REG_DWORD

Range: 0 to Unlimited

Default: 4 per processor

This parameter specifies the number of I/O worker threads to create per processor. Each pool thread watches for a network request and processes it. The MaxPoolThreads count does not include threads that are consumed by ISAPI applications; it refers only to the number of worker threads available to process request for static files. IIS will create more threads as needed to process ISAPI requests. The total number of IIS worker threads is capped by PoolThreadLimit.

By default, only four CGI applications can run concurrently. If you run many CGI applications, you should increase this value in order to increase the throughput. You could set the UsePoolThreadForCGI value (under \Services\W3SVC\Parameters) to FALSE (0); however, this is somewhat dangerous because it can significantly decrease performance during high usage of CGI applications. Generally, it is not good to create more than 20 threads per processor.


ListenBackLog REG_DWORD

Range: 1 to 300

Default: 15

This parameter specifies the maximum number of active connections to hold in the queue while they wait for server attention. Enhanced IIS 5.0 functionality generally makes it unnecessary to use or modify this entry, although with extremely heavy use it could be beneficial to increase this value up to 300.

Registry Path:

 HKEY_LOCAL_MACHINE\SYSTEM  \CurrentControlSet  \Control  \SecurityProviders  \SCHANNEL


ServerCacheTime REG_DWORD

Range: 0 to Unlimited (measured in milliseconds)

Default: 300,000 milliseconds (5 minutes)

This parameter determines the amount of time an SSL session lasts. Once an SSL session has been established, clients can reconnect to that session at a fraction of the resource cost of the initial connection. If the SSL session expires, a new SSL session must be completely established. This parameter is not present by default. To change its behavior, you must add it to the registry. You should evaluate how long you expect SSL sessions to last, and then set this parameter slightly longer. Do not make the timeout much longer than your estimate or this cache may begin to store stale data. For further discussion, see the "Security" section.



Microsoft Application Center 2000 Resource Kit 2001
Microsoft Application Center 2000 Resource Kit 2001
ISBN: N/A
EAN: N/A
Year: 2004
Pages: 183

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net