What timeouts govern worker process shutdown when stopping an application pool - asp.net

I have an ASP.NET (.NET Framework) site running in IIS. The site has a long-running background process and when the application pool is stopped as part of tearning down an active VM I'd like for the w3wp process to continue running until the background process shuts down gracefully (which can take a long time).
We leverage a custom IRegisteredObject to plug into ASP.NET shutdown; our code does not return from the Stop(true) call until the background process shuts down.
When we stop the application pool, we see in our logs that Stop(false) is called and then Stop(true) is called 30s later like we expect. However, before Stop(true) returns IIS is simply killing the worker process. This kill happens five minutes after the initial Stop(false) call. We'd like to extend this timeout.
In IIS itself, we have App pool->Process Model->Shutdown Time Limit to 1000s. Lowering this value below 5 min can make the kill happen sooner, but raising it above 5 min does not prevent the kill at 5 min.
Is there some other timeout setting that governs this shutdown? Is it possible to go beyond 5 minutes?

The shutdown time limit hint leaves the old worker process running for up to the number of seconds indicated. If all requests are completed prior to that time, then it will shut down earlier. this is why you lower the value below 5 minutes to make the killing happen sooner.
And the maximum shutdown timelimit seconds appears to be 4294967, this is more than 5 minutes, But if there is not enough free memory, it will cause no more than 5 minutes.

Related

Can IIS AppPool be unavailable due to idle?

I have a ASP.NET application running on IIS 8. My application sometimes does not respond to request with clients logging a timeout and then IIS starts sending out 503 Unavailable response codes. Each outage seems to last 5 minutes which corresponds to a 5 minute limit interval for Kill w3wp.
I have the App Pool configured for a Kill w3wp limit action with limit percentage of 80%.
While it might seems the pool is getting killed due to high CPU usage, I could not find any records in the event viewer. In fact, it had gone to idle state because of no requests in about 25 minutes.
The crash happened with 3 simple identical requests issued when the pool was idle.It cannot be reproduced manually in any environment.
This is happening about once a week. Since its a critical application, its running on a separate server with no other applications installed.
I have changed the Limit from Kill to throttle but I am not sure its a good idea. Anyways I've got to find a way to reproduce this.
Can the pool fail to exit an idle state?
If there is no traffic, w3wp.exe may go idle aka stop running. But that is not the same as it being truly stopped and it would not cause a 503. It would just start back up on the next request.
A 503 is more likely because your IIS App Pool is crashing or literally being stopped.
I would check Windows Event Viewer to see if says anything around that time frame around w3wp crashing. You can also set IIS to do more detailed logging anytime your w3wp app pool is stopped, started, recycled.
Docs about enabling more app pool logging:
https://technet.microsoft.com/en-us/library/cc753412%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396
You could also search various IIS logs for errors:
https://stackify.com/beyond-iis-logs-find-failed-iis-asp-net-requests/
If you set auto recycle option then remove it and make it schedule recycle instead.
It seems as the memory consumption by your application tends to saturation level, IIS being recycled

How to get fast ASP.Net application shutdown for restart/recycle on high traffic site?

I'm running a very high traffic site that gets a good 300+ requests/second (http://cooltext.com). A restart takes a good 90 seconds at least for it. So every time I post a new build it goes down for a minute or two. Long enough to trigger my monitoring services.
When I make a change that restarts the server, it appears that the restart stalls until all of the old requests on the old application pool (some of them very long running) complete. I can make the restart happen much faster by killing the old w3wp.exe instance manually.
Is there some way to force IIS to close all the connections right away and do a hard restart? Some setting in IIS or asp.net to control this?
Just found the following that appears to be what I'm looking for: http://msdn.microsoft.com/en-us/library/aa720127(v=vs.71).aspx
Shutdown Time Limit is the equivalent application pool setting for the shutDownTimeout ASP.NET process model setting. It specifies the amount of time a worker process is given to shutdown gracefully. If the worker process does not shutdown in time amount specified, the ASP.NET ISAPI will end the worker process. Shutdown Time Limit is set to 90 seconds by default. You can specify a different time limit by changing the value in the spin box.

web app slow performance when leave idle for some time

We have a web application deployed on IIS 7.5 target framework 4.0
the application perform slow when leave idle for few minutes for first time and then perform as expected this happened each time application is idle.
With the help of fiddler I found its TCP/IP connection which is taking time about 21 secs whilein subsequent calls this time is 0.
The Idle time out is also set high and connection time out is also high in the IIS settings.
server is - Windows 2008 R2.
there is nothing in the event viewer related to the website.
we used form authentication but the time out for that is also set about 10 hours in the config file.
Can anybody point me to the setting with is affecting the response time after the app is idle for some time.
Note - this was working proper when deployed withing the LAN but this problem starts when deployed out of the LAN or in separate domain.
Problem
here is the problem in IIS app pool idle time out, its by default set to 20 minutes, after 20 minutes app pool shutdown if no request within 20 minutes,
when any request comes after 20 minute its again start,
The problem is that the first visit to an app pool needs to create a new w3wp.exe worker process which is slow because the app pool needs to be created, ASP.NET or another framework needs to be loaded, and then your application needs to be loaded. so it may take time 20-30 seconds or depends on the application content size.
Solution
so to avoid this type of delay we need to set the idle time out to 0.
now it will always load fast.
app pool setting
The IIS application pool is shut down after 30 minutes of inactivity. After that, when you make a request IIS basically has to start the website up again, which leads to the behavior you are describing. You can change the idle time of your website in IIS though to avoid it.
You could also look into the Auto-Start feature of the 4.0 framework.
Well, a bit late, but may help someone else. I had the same problem, nothing in the logs, spent days, then looking at the network adapter properties / configuration / power management - Allow computer to shut down save power was checked. Unchecked and the problem was solved.

IIS application pool recycling and "shutdown time limit" role in overlapping

When recycling happens, I want to move all new request to new w3wp (this is done automatically) and leave the previous w3wp to exit when it gets idle (whatever time it takes).
There's a shutdown time limit config for application pools (I use IIS 7.0) which doesn't take 0 as a value. How can I let the previous w3wp to shutdown when it is done and idle.
The shutdown time limit hint leaves the old worker process running for up to the number of seconds indicated. If all requests are completed prior to that time, then it will shut down earlier.
When recycling happens, a new worker process spins up and immediately begins taking new requests. The old worker process continues working on old in-flight requests until completed, or until the shutdown timelimit is reached. By the way, the maximum shutdown timelimit seconds appears to be 4294967 which is one second shy of 50 days. OMG I hope no one is waiting that long for a request to complete!
Parenthetically, it is possible for a new worker process to NOT actually be able to start, especially if there is not enough free memory.

Overcome compilation(?) pause on *secondary* initial ASP.Net application startup?

After deploying an ASP.Net application to a new server, the first user to hit the app gets a long pause, presumably because the app is performing its initial compilation. However, this pause seems to also also occur after the application has timed out and unloaded itself from memory.
The first compilation would be tolerable as it only happpens once, but the 2nd one seems to me like it should be unnecessary....is there a workaround to address this issue? It would be nice to be able to extend the application timeout, but I only see a way to extend the session timeout, which I would rather not do, as this would keep all user sessions in memory for a long period of time.
That's IIS shutting down the worker process - the default is a 20 min idle time. In IIS6, you can configure the app pool and turn off the Idle timeout (on Performance tab). In IIS7, it's in the Advanced Settings.
A common way (though looks hackish to me) to keep the worker process alive is to have some program issue web requests to some URL in the application on a regular basis.
You can reduce the initial startup time by precompiling the ASP.NET app with aspnet_compiler.exe. This won't reduce the initial request time to zero (it'll still need to create the worker process and do other housekeeping.) but it'll noticeably reduce it.
I did find some recommended settings for the App Pools in IIS. The intended outcome of these settings is to reduce the number of times your application needs to go through the startup cycle. These settings should apply to IIS 6 as well as IIS 7:
Recycle Worker Process: Disable. Use this only if you have multiple websites and are trying to isolate processes.
Shutdown worker processes after being idle for (time in minutes): Disable unless you are sharing resources on your server. With this setting disabled, your website should not unload, ensuring that startup time for your site is as minimal as possible.

Resources