Let's take a look at some questions about the application pool. The "properties" dialog box of the application pool has four pages: recycle, performance, running status, and ID, as shown in figure 6. Among these option pages, the most striking is probably the "recycle" page, which can be used to manage the collection of worker processes. In work process Isolation Mode, IIS can be configured to regularly restart work processes in the application pool to better manage those work processes. This ensures that the applications in the pool run normally and the lost system resources can be recovered. In order to recycle the worker process, the failure Worker Process's ability to receive requests will be limited until it processes all the remaining requests stored in the Request queue. To discharge the current request, you can restrict the Process configuration. The replacement Worker Process of the same namespace group starts before the old worker stops to prevent service interruption. The old process completes its pending requests and closes normally, or if it reaches the configured time limit, number of requests, the set time schedule, or when it reaches the specified
MemoryIf the application is still disabled, the process is terminated explicitly. By default, the application pool is recycled every 1740 minutes (29 hours.
W3SVC checks whether the application pool runs properly based on the options on the "running status" page, including pinging the Worker Process at specified times, in seconds, the default value is 30 seconds. (The worker must start within the specified time period) whether to enable quick failure protection (if a certain number of worker processes fail within the specified period of time, the application pool is disabled ). In addition, ISAPI applications (includingASP. NET and asp. dll) can declare that they are no longer suitable for providing services and require recycling.
By default, When IIS 6.0 recycles a pool, it uses a recycling technology called overlapped recycle. In this recycle mode, failed worker processes remain running and a new worker process is created. IIS 6.0 passes the new incoming request to the new working process, but does not remove the old working process until the old Working Process completes the request in its queue or encounters a timeout error. During this period, TCP/IP connections will not be lost because http. sys maintains the connection validity. When a failed working process times out and fails, the next request sent to the working process is a new request, so the session information originally stored in the process will be lost. All such recycling operations are performed automatically without administrator intervention. In most cases, service interruption is not caused. If necessary, set the value of LogEventOnRecycle to 1, indicating that an event log is generated when W3SVC executes the recycle operation.
For applications that cannot run on multiple instances, overlapped recycle recycling technology may cause problems. If you encounter such problems, you can set the value of DissallowOverlappingRotation to True (1) to disable the process "overlapping" during the recycle operation of an application pool. In addition, for failed working processes, we may not want to remove them, but keep the process to detect and find the root cause of the problem, in this case, you can set the configuration data attribute OrphanActionExe to the name of the execution file, so that the execution file remains running when the process becomes "Orphan.
Another feature related to the application pool is that IIS 6.0 allows you to configure an application pool as a Web Garden ). To understand the concept of Web garden, we can imagine a situation where there is an IIS 5.0 server and three Web sites, each of which runs the same application, if IIS 5.0 is able to automatically send requests to the equivalent and actually isolated Web websites based on the circular loop mode and separate the loads to three different processes, it can form a small Web Farm (Web Farm)-this is the Web garden.