IIS 6.0 applies the new process model. The kernel-mode HTTP listener (HTTP. sys) receives and sends HTTP requests (or even uses its response cache to satisfy requests ). The working process registers the URL sub-space. http. sys sends the request to the corresponding process (if the application pool is used, the request is sent to the process set ).
Figure 4 shows the differences between IIS 5.0 and IIS 6.0 process models. IIS 5.0 uses WinSock to accept connections on port 80. The Inetinfo process is responsible for receiving the request, or executing the request within the process, or handing it over to the DLLHOST process for processing outside the process (for the purpose of isolation ). The response is sent back by the Inetinfo process. Figure 4 IIS 5.0 and IIS 6.0 process models IIS 6.0 processes depend on the kernel-mode web driver HTTP. sys. In the new model, HTTP. sys manages connections and Processes requests. The request may be full through the HTTP. sys cache or be handed over to a worker process for further processing (see figure 5 ). You can configure multiple working processes to isolate them with low overhead. HTTP. sys includes a response cache. When the request matches an entry in the response cache, HTTP. sys directly sends the cache response from the kernel mode. Figure 5 shows how requests are processed through HTTP. sys (Requests may also be forwarded to a worker process for processing ). Figure 5 request processing in IIS 6.0 because the Web Server includes both kernel-mode components and user-mode components, both components must be adjusted at the same time to achieve optimal performance. Therefore, to adjust IIS 6.0 for a specific load, You need to configure the following content: http. sys (kernel-mode driver) and related kernel-mode cache. · Working process and user mode IIS, including application pool configuration. In addition, we will discuss other parameters that affect performance later.
Kernel Mode AdjustmentPerformance-related HTTP. sys settings can be divided into two types: Cache Management, connection and request management. All Registry settings are saved in the following entries: HKEY_LOCAL_MACHINE/system/CurrentControlSet/services/HTTP/parameters if the HTTP service is running, you must stop the service and restart the computer, to make the settings take effect.
Cache Management settingsOne of the advantages of HTTP. sys is the kernel mode cache. If the response is in the kernel cache, it may be able to fully satisfy an HTTP request in the kernel mode, which can obviously greatly reduce the overhead of CPU processing requests. However, the IIS 6.0 kernel-mode cache is a physical memory-based Cache. Each entry occupies a certain amount of memory space. Slow-store entries can only be used to provide benefits. However, an entry occupies physical memory at any time, whether or not it is used. Therefore, you need to evaluate the benefits of caching a project (the request can be satisfied directly from the cache) and its overhead throughout the life cycle (the physical memory needs to be occupied, consider the availability of resources (CPU, physical memory) and workload. HTTP. sys tries to only save useful (frequently accessed) projects in the cache. However, if HTTP is adjusted for a specific workload. sys cache, the performance of the Web server can be improved to a certain extent. The following are some useful cache settings for HTTP. sys Kernel Mode: · urienablecache. Default Value: 1. If it is set to a non-zero value, Kernel Mode Response and segment cache can be enabled. For most workloads, the cache should be enabled. If you want ultra-low response and low cache utilization, disable caching. · Urimaxcachemegabytecount. Default Value: 0. If it is set to a non-zero value, you can specify the maximum amount of memory that can be used by the kernel cache. The default value is 0, which allows the system to automatically adjust the amount of memory that can be used by the cache. Note: You can only set the maximum amount of memory that can be used, and the system may not allow the cache to grow to the specified size. · Urimaxuribytes. Default Value: 262144 bytes (256 KB ). This parameter sets the maximum length of each entry in the kernel cache. Responses or segments larger than this length are not cached. If you have enough funds, you can increase the value of this parameter. If the funds are limited and large entries squeeze out smaller entries, you can set this parameter to a smaller value. · Uriscavengerperiod. The default value is 120 seconds. A scavenger program regularly scans the HTTP. sys cache. Entries that have not been accessed during the two scans will be deleted. You can set the scan cycle to a high value to reduce the number of scans. However, if old entries with low access frequency are still stored in the cache, the memory occupied by the cache will continue to increase. If you set this period too low, the scan frequency will be too frequent and may cause excessive cleaning and disturbance of slow storage.
Request and connection management settingsIn addition, HTTP. sys manages inbound HTTP/HTTPS connections and is the first layer on which requests are processed. It uses an internal data structure to save connection and request information. Although such a data structure can be created (or released) as needed, if you save some data structures in the look-aside table for backup, you can achieve higher CPU efficiency. Saving such reserves helps HTTP. sys to use fewer CPU resources to handle load fluctuations. Note: Load fluctuations may not be caused by external load fluctuations. Some internal optimization measures designed to improve batch processing or interrupt mediation may also lead to load fluctuations and fluctuations. Reserve helps reduce CPU usage and shorten the delay time. It also increases the processing capability of the web server, but also increases the memory usage. When adjusting HTTP. sys requests and Connection Management Behaviors, you must remember the following factors: available server resources, performance goals, and workload characteristics. You can use the following request and connection management settings: · maxconnections. This setting controls the number of concurrent connections allowed by HTTP. sys. Each connection consumes a non-Paging pool (a valuable and limited resource ). The default value is quite conservative to limit the number of non-Paging pools used by connections. For dedicated web servers with sufficient memory, you can set this value to a higher value if a large number of concurrent connections are expected. The larger the value is, the more non-Paging pools are occupied. Therefore, be careful to use a correct value that suits the system configuration. · Idleconnectionshighmark, idleconnectionslowmark, and idlelisttrimmerperiod. these values are used to control the processing of non-parallel connection structures: the number of available connections that must be provided at a certain time (used to handle connection load fluctuations), the upper and lower limits of the release list, and the frequency of cut and supplement of the connection structure. · The requestbufferlookasidedepth and internalrequestlookasidedepth values control the processing of the data structure related to buffer management, and the amount of reserves to cope with load fluctuations.
User Mode settings
IIS Registry SettingsThe following registry settings can be found in the following entries: HKLM/system/CurrentControlSet/services/inetinfo/parameters/· maxcachedfilesize (REG_DWORD), in bytes. Determines the size of the files that can be cached (256 kb by default ). The actual value depends on the maximum number and size of files in the data table and the number of available Ram. Caching large files that are frequently accessed can reduce CPU usage, disk access, and latency. · Memcachesize (REG_DWORD), in MB. Restrict IIS user-mode cache to the specified size (by default, the cache size is adjusted by IIS based on the number of available memory ). Based on the size of the "popular" file set (frequently accessed file sets), the number of Ram resources, or the IIS process address space (normally 2 GB or less ), select the value of this parameter. · Disablememorycache (REG_DWORD ). If it is set to 1 (the default value is 0), the user-mode IIS cache is disabled. When the cache hit rate is very small, the cache can be completely disabled to avoid overhead related to the cache code path. · Maxpoolthreads (REG_DWORD ). Set the maximum number of threads in the pool that can be created by each processor (the default value is 4, and the range is not limited .) Every pool thread observes network requests and processes them. The maxpoolthreads count does not include the threads currently processing ISAPI applications. If the average CPU usage is not in the optimal state, you should increase the value of this parameter because all existing threads are busy and there are no available threads used to process new requests. · Poolthreadlimit (REG_DWORD ). Set the maximum number of pool threads that can be created by the system (the default value is 4 times the number of processors, and the range is not limited ). Poolthreadlimit must be greater than or equal to maxpoolthreads. Under normal circumstances, the number of poolthreadlimit = maxpoolthreads processors. It is not enough to set only one of the parameters. If the maxpoolthreads and poolthreadlimit parameters are specified at the same time, stricter restrictions can be imposed. · Objectcachettl (REG_DWORD), in seconds. Controls the duration of an object that has not been accessed in the IIS user mode cache (the default value is 30 seconds, for example, 0xffffffff, the object cache scavenger thread is disabled ). If the system has enough memory and the submitted content does not change frequently, you can increase the value of this parameter. If the system memory is insufficient and the user mode cache size is increasing, this parameter should be lowered. See activityperiod in this section. · Activityperiod (REG_DWORD), in seconds. Files can be cached only when they are repeatedly hit within the active period (10 seconds by default, and this option is disabled if it is set to 0. This parameter reduces the cache overhead caused by files that are not frequently accessed by the cache. If the cache content does not change much and there is not enough available memory, the activity duration can be increased; alternatively, if a large number of request loads exist in the cache, the activity duration can be reduced. · Datasetcachesize (REG_DWORD): The default value is 50. Set the maximum number of virtual directory entries in the database dataset cache. If the number of installed virtual directories exceeds the default value, you can increase the value of this parameter. When submitting static content, a low-capacity dataset cache increases the latency (lower throughput and lower CPU usage ).
IIS metabaseThe following settings can be found in w3svc. · Aspmaxdisktemplatecachefiles. Enable disk caching for ASP script templates. Compiling an ASP template is a task that consumes a lot of CPU resources. The memory size limits the number of templates that can be cached in the memory. Retrieving the compiled template from the template cache on the disk requires less overhead than the template not in the compiled ASP memory cache. See the aspscriptenginecachemax section below. · Aspdisktemplatecachedirectory. If possible, you can set it to a disk that is not frequently used (for example, a disk that is not shared with the operating system, paging files, IIS logs, or other frequently accessed content ). The default directory is "% WINDIR %/system32/inetsrv/template disk cache/asp compiled templates ". · Aspscriptenginecachemax. Set it to the maximum number of script engines allowed by the memory capacity (125 by default ). · Aspscriptfilecachesize. Set the maximum number of ASP templates allowed for memory capacity (250 by default ). See the aspmaxdisktemplatecachefiles section in the previous article. · Aspexecuteinmta. If you want to detect errors or faults when delivering some ASP content, set this parameter to 1 (Enabled ). For example, if you want to host multiple sites and each site runs under its own work process, you can enable this parameter. Errors can be seen in the COM + section of the Event Viewer. This setting enables the multi-threaded unit model in ASP (the default value is 0, indicating that the unit model is disabled ). · Aspprocessorthreadmax. If the current setting (the default value is 25) is insufficient to meet the load requirements (which may lead to errors in some requests), you can increase the value of this parameter. · Centralbinaryloggingenabled. Set this parameter to true to enable centralized binary logging. Binary IIS logging reduces CPU usage, disk space usage, and disk I/O operations. Centralized binary logs can be directed to a binary file regardless of the number of hosted sites. A post-processing tool is required to analyze logs in binary format.
IIS workflow options (IIS Admin UI, application pool attributes)In the absence of administrator intervention, service restart, or computer restart, the IIS workflow recycling option on the IIS management interface provides an effective solution for an emergency fault or event. Such a situation includes memory leakage, which may increase the memory burden, or cause the worker process to enter the unresponsive or idle state. Under normal circumstances, you may not need to enable the recycle option, so you can disable it (or configure the system to perform the recycle operation at a very low frequency ). In the following section, the name of the italic is the per-app-pool variable. When using scripts to set these variables, you can use the path "/lm/w3svc/apppools/N", where n represents the application pool index. There are three options, as shown in the following table: · recycling options. You can find it on the recycle tab. · Performance options. You can find it on the performance tab. · Job process health monitoring options. You can find it on the "Health" tab. Table 8. recycling options
| Parameters |
Description |
| Periodicrestartrequests, DWORD. The default value is disabled. The default value is 35000. |
Regular recovery by Time |
| Periodicrestartrequests, DWORD. The default value is disabled. The default value is 35000. |
Regular recovery based on the number of requests (accumulative) |
| Periodicrestartschedule and multisz; disabled by default; empty string value by default |
Reclaim at the specified time |
| · Periodicrestartmemory, DWORD; default value: 512 MB · periodicrestartprivatememory, DWORD; default value: 192 MB |
If one of the following conditions is met, memory-based reclaim (disabled by default) will allow the recycle Worker Process: · Maximum capacity of virtual memory · if the maximum capacity of used memory is facing increasing pressure on memory capacity, one or all of the parameters can be set based on strict memory capacity standards, frequently recycles working processes to relieve memory pressure. |
Table 9. Performance options
| Parameters |
Description |
| Idletimeout, DWORD, in minutes, default value: 20 |
When the idle time of a process exceeds the specified time, close the working process. This can save a limited amount of memory resources, but if the CPU load is heavy and new working processes need to be started frequently, we do not recommend this approach, because the process creation will bring a certain amount of overhead. |
| Apppoolqueuelength, DWORD, default value: 2000 |
Limit the length of the kernel Request queue for each application pool (app-pool. The request consumes a paging pool. When there is a large demand for the paging pool, the value of this parameter should be lowered. If the length exceeds the specified length, the server rejects the request and generates a non-custom error number 503. |
| Cpuaccounting, Boolean, disabled by default (0), enabled as 1 |
Monitor CPU usage. You can set the maximum CPU usage (cpulimit, DWORD, default value: 0) and monitoring refresh cycle (cpuresetinterval, DWORD, default value: 0, in minutes ). If the CPU usage limit is reached, or no operation is performed (but an event is written in the event log), or the worker process (cpuaction, DWORD, default value: 0, indicates "no action is taken"; the maximum value is 1, indicating "Closing the Working Process "). |
| Maxprocesses. Default: one worker process is used to process all requests. |
You can control the total number of work processes in the Web garden mode. In Web garden mode, several worker processes are responsible for processing the request load under a single application pool. No working processes were pre-assigned to the web site through different application pools. In some cases, a worker process cannot meet the processing needs of the load (this can be seen through poor CPU usage and long response time ), increasing the number of worker processes helps improve the system throughput and CPU usage. When hosting multiple sites, you can consider using the Web garden mode. In addition, when one of the processes suddenly crashes, using multiple working processes also provides more reliability, and almost no service interruption occurs. Compared with the pre-allocated application pool, the Web garden mode is easier to set and control. |
Table 10. Health options
| Parameters |
|
Description |
|
| Pingingenabled, Boolean, default value: 1 pinginterval, DWORD, default value: 30 seconds |
|
Ping the Working Process (pingingenabled) at a fixed interval (pinginterval ). If there is no response, it is deemed that the working process has an error. IIS will try to terminate the process and generate a new process. |
|
| Rapidfailprotection, Boolean. The default value is rapidfailprotectionmaxcrashes and DWORD. The default value is rapidfailprotectioninterval and DWORD. The default value is 5 minutes. |
|
Set the maximum number of failures allowed to be generated (rapidfailprotectioninterval) within a given period of time (rapidfailprotection-maxcrashes) to control the rapidly occurring failures (rapidfailprotection ). If a failure rate is specified, the application pool is disabled and related information is written to the event log. |
|
| Startuptimelimit, DWORD, 90 seconds by default |
|
Control the start time of a working process. If the start time exceeds this time, it is deemed that a fault has occurred. |
|
| Shutdowntimelimit, DWORD, 90 seconds by default |
|
If the shutdown time of the working process is exceeded, the process is considered to be in the non-responding State. |
|
Security Socket Layer Adjustment ParametersThe use of Secure Sockets Layer (SSL) will increase the CPU burden. The most resource-consuming part of SSL is the overhead required to establish a session (including a full handshake), the overhead of reconnection and the overhead of encryption/decryption. To achieve better SSL performance, perform the following operations: · enable the "keep active" feature of the SSL session. This eliminates the overhead required to establish a session. · If possible, re-use sessions (especially for traffic that does not "keep active ). · Note: the longer the key, the higher the security, but the more CPU time required. · Note: not all page components require encryption. However, a mix of plain text HTTP and HTTPS may cause a warning to pop up in the client browser, notifying that not all page content is protected.
ISAPIThere are no specific adjustment parameters for isapis. If you write a private ISAPI extension, ensure that the Code is efficient in execution and resource usage. See other problems that affect IIS performance later.
Managed code Adjustment Parameters· Make sure that all scripts have been compiled in advance. You can call a. Net script in each directory to complete this task. After compilation, You need to reset IIS. After modifying machine. config, Web. config, or any. aspx script, you must re-compile the script. · If you do not need session status information, make sure that this project is disabled on each page. · When you run multiple hosts containing ASP. NET scripts in the isolation mode (one application pool for each site), you should monitor the memory usage. Configure sufficient memory for the IIS server based on the number of application pools that are expected to run concurrently. Consider using multiple application domains (app-domains) where multiple isolation processes exist ).
Other problems affecting IIS Performance· Install a filter without cache awareness. Installing a filter without the HTTP cache awareness will cause IIS to disable all the caches, resulting in a sharp decline in performance. The old ISAPI filter (the filter compiled before IIS 6.0) may have this problem. You can use the HTTP cache filter to mark the configuration database as a cache-aware filter. · CGI request. For performance considerations, we do not recommend using CGI applications to process requests. Frequent Creation or Deletion of CGI processes results in a large amount of system overhead. A better alternative is to use the ISAPI program and ASP (or ASP. NET) scripts. These methods can be isolated.
NTFS file system settingsNtfsdisablelastaccessupdate (REG_DWORD) 1 under HKLM/system/CurrentControlSet/control/filesystem. By disabling update of the date and time stamps of the last accessed file or directory, this system-wide Switch Parameter reduces disk I/O load and reduces latency. This key does not exist by default, so you need to add it. If the operation contains a large dataset (or a large number of hosts) with thousands of directories, the effect of disabling update is very obvious. If you only need to retain the information web for Web management, we recommend that you use IIS logs instead. Warning some applications (such as Incremental Backup tools) need to use the update information. If this information is not available, it will not work properly.
Application pool attribute of IIS 6 [18:42:08 | Author: ychon] font size: large | medium | small
Reclaim
In the recycle tag, you can set the recycle method of the Worker Process:
Recycle Worker Process (minutes): the number of minutes after which the worker runs to recycle the worker process. It is enabled by default and set to 1740 minutes (29 hours );
Reclaim A Worker Process (number of requests): The number of HTTP requests processed by the worker process before terminating the worker process. This is disabled by default. If it is enabled, the default value is 35000;
Recycle a worker at the following time: Recycle the worker at the specified time. disabled by default. To enable it, select the check box and click Add to add the recycle time, use 24 hours to define the time for the rollback;
When too much memory is consumed, recycle the Worker Process:
Maximum virtual memory (MB): The worker process is reclaimed when the virtual memory used by the worker process reaches the set value. The default value is 500 mb if enabled; we recommend that you set it to no more than 70% of the total virtual memory;
Maximum memory used (MB): The worker process is reclaimed when the physical memory used by the worker process reaches the set value. The default value is 192 MB if enabled; we recommend that you set it to 60% of the total physical memory size;
In addition, the application pool has the following two ways to recycle working processes, but neither of them will interrupt Web Services:
By default, application pools use overlapping collection methods. In this way, when the application pool needs to shut down a working process, a working process is created first until the new working process is successfully created;
The application pool can also shut down the old working process and then create a new working process.
If the web application does not support running multiple instances, you must configure the application pool to prohibit overlap collection. This configuration cannot be modified in the IIS console. You can only modify the disallowoverlappingrotation metabase attribute of the corresponding application pool in metabase. XML to true.
Performance
In the performance tag, you can set the running mode of the Worker Process:
When idle for this period of time, shut down the working process (minutes): How many minutes after the working process is idle, which reduces the consumption of idle working processes on system resources and CPU performance, enabled by default and set to 20 minutes;
The core Request queue is limited to (number of requests): When HTTP. when sys receives an HTTP request from a client, if the worker process of the corresponding application pool processing the request is still busy, HTTP. sys stores the received requests in the Request queue of the corresponding application pool until the worker process is idle. This option is used to set the number of requests that the request queue of this application pool can accommodate. By default, the request queue of each application pool is limited to 1000 requests, if the number exceeds 503, the system returns the 65535 error to the client. You can modify the value as needed. The maximum value is. However, setting too large will consume a lot of system resources, and setting too small will cause frequent 503 errors during client access.
Enable CPU monitoring: monitors the CPU usage of this application pool, which is disabled by default. If an application pool occupies too many CPU usage, you can configure this option to restrict the application pool;
Maximum CPU usage (percentage): The maximum CPU usage that can be used by the configured application pool. The default value is 100 when CPU monitoring is enabled;
Refresh CPU usage (minutes): interval between refresh CPU usage; default value: 5 when CPU monitoring is enabled;
The operation performed when the CPU usage exceeds the maximum usage: When the CPU usage of the application pool exceeds the set maximum CPU usage, the default setting is none when CPU monitoring is enabled, in this case, IIS only records the event logs without performing other operations. If you choose to disable IIS, IIS will close all worker processes in the application pool;
Web Garden: in the Web garden, you can configure the maximum number of worker processes used by this application pool. The default value is 1 and the maximum value is 4000000; configuring multiple worker processes can improve the performance of the application pool to process requests. However, before you configure multiple worker processes, consider the following:
Every working process consumes system resources and CPU usage. Too many working processes will lead to a sharp consumption of system resources and CPU usage;
Each worker process has its own status data. If a web application depends on a worker process to save status data, multiple worker processes may not be supported.
Running status
In the running status tab, you can configure the application pool to monitor the running status of the worker process,
Enable Ping: by default, the application pool is configured to ping the worker process every 30 seconds. When the worker process does not respond, it is deemed that the working process has a fault and is disabled by default. You can modify the ping interval, but too Long Ping interval may cause web service interruption, and too short Ping interval will consume more system resources and CPU utilization, therefore, we recommend that you retain the default configuration;
Enable quick failure protection: if there is a problem with writing web application code, it may cause the working process to continue to have problems. By default, the application pool is configured to enable quick failure protection. When the worker process is configured for a period of time (5 minutes by default) if the number of failures in the application exceeds the configured value (5 by default), the application pool is disabled.
Start time limit: IIS waits for the start time of a worker in the application pool. When the start time of a worker exceeds the set value, IIS will record it in the event log;
Closing time limit: When IIS detects a worker process failure, it marks the worker process as disabled. This option specifies the time limit for IIS to wait for the Worker Process to automatically close, if the worker process is not closed after the time limit is exceeded, IIS forcibly closes the worker process.
Identifier
In the tag, you can configure the user account that the workflow runs. In IIS 5 or When IIS 6 runs in IIS 5 Isolation Mode, the working process runs in the local system account, IIS 6 running in work process Isolation Mode runs under the network service account, which reduces the possibility of system attacks.
You can configure a workflow to run under a predefined local system, local service, or network service account, or use a Custom User Account. We recommend that you use the default network service account. For higher security, you can configure a user account. However, we recommend that you add this user to the iis_wpg user group, therefore, the iis_wpg user group has the minimum permissions to start and run a working process.
