I met an issue in ASP.Net. In any Web App config Web.config file there is a section called httpRuntime, and it has an attriube: shutdownTimeout. According to MSDN documentation, this attr specify how long the idle time of the worker process is allowed before ASP.Net runtime to terminate the worker process. On another side, under IIS's ApplicationPool's -> Default AppPool -> properties -> performance tab, there is a setting: "shutdown worker process after being idle for (20) minutes".
I guess that under IIS, this setting is for all worker process which is used to handle incoming request not only the process where a specific ASP.Net runtime resides. And if Web.Config's shutdownTimeout has not taken effect yet, the IIS's setting would then do its work.
However from my observation, although the httpRuntime's shutdownTimeout default value is 90 seconds, my web application was always shut down after idle for 20 minutes. It seems the IIS setting take priority for this aspect.
It is much appreciated if somebody could clarify on this: what is wrong with my guess.
I did some digging and found out the answer:
the attriubte shutdownTimeout controls how long the ASP.Net runtime will shut down the worker process before it gracefully exits by itself if it is asked to terminate by the ASP.Net runtime.
Is this right, any opinion is greatly appreciated.
https://msdn.microsoft.com/en-us/library/e1f13641(v=vs.100).aspx
Specifies the number of minutes that are allowed for the worker process to shut down. When the time-out expires, ASP.NET shuts down the worker process.
The default is 90.
So basically, the worker process has X minutes to shut down the worker process. If it reaches X it is killed.
Related
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.
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.
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.
I have a ASP.NET web application running on an IIS6 server. The application is making potentially long running calls to a xml service on a remote machine. Some of the service calls on the remote machine are taking a long time to execute (sometimes up to 4 minutes). The long term solution would be to make the calls asyncronous, but as a short term solution we want to increase the timeout for the calls and the overall httpRequest time out.
My fear with this is that the long running calls will fill up the request queue and prevent the "normal" page requests from completing. How can the server, IIS and application settings be tuned to temporarely resolve the issue?
Currently there are approximately 200 page requests/minute and this results in 270 service requests/minute.
The current executionTimeout is 360 (6 minutes)
The current service call time out is 2 minutes
There's this article on Microsoft's Knowledgebase that has some pretty much all the information you might need:
* Contention, poor performance, and deadlocks when you make Web service requests from ASP.NET applications
I will give you some research I have done regarding some of the specific items handled in the article above. This information below applies to IIS6, comments for IIS7 where applicable.
Increase the Processor Worker Thread pool from 25 to at least 100
The default values for the Threadpool size is 100 because the default value for autoConfig is true.
The values covered by autoConfig is
maxWorkerThreads
maxIoThreads
maxConnection
There is one value that is still 25 that must change is – ASPProcessorThreadMax, this can only be set in the IIS metabase (via adsutil tool) in IIS6. [IIS7’s equivalent is the processorThreadMax value]
So I'm opting not to change the machine.config settings as they are fine and there are other paramaters that would be affected by turning off autoconfig, but rather change ASPProcessorThreadMax from 25 to 100 via the IIS metabase (the only way to change this value).
e.g.
cscript %SYSTEMDRIVE%\Inetpub\AdminScripts\<nowiki>adsutil.vb</nowiki>s SET W3SVC/AspRequestQueueMax 100
Max connections per server
maxconnection
The autoconfig sets this value to 12*number of cpu’s, that’s how many connections can be made to each address you are connecting to at one time.
Debugging
Here are some things you can do:
Monitor if requests are waiting in the queue
Monitor the following counter:
Run perfmon
Add counter: ASP.NET Applications/Requests In Application Queue
This will show us if work items are queued because of a shortage of workers.
Check Identity Used by Application Pool
Open IIS Manager
Check which application pool is used by your site in IIS manager.
Choose the Application pool being used in the Application Pools list, then Right Click -> properties and see what account identity is being used.
It should be Network Service by default.
I'm trying to debug a problem (exception being thrown) in an ASP.NET MVC program using the Microsoft CLR Debugger. It works pretty well, except after a minute or two, the debugger gets detached (the web request times out or something?) and I can no longer inspect its state.
This is extremely frustrating. How can I make the server/debugger (not sure who is at fault here) stay open until I tell it to stop?
Its on the IIS side, check this on how to configure/fix: http://vaultofthoughts.net/ASPNETDebuggerTimeoutInWindowsVista.aspx
From the link:
In IIS 7 go to the Application Pools and select the Advanced Settings for the pool which you process runs in. In the Process Model section you can do one of two things;
Set the Ping Enabled property to False. This will stop IIS checking to see if the worker process is still running and keep your process alive permanently (or until you stop your debugged process)
If you prefer to allow IIS to continue the monitoring process then change the Ping Maximum Response Timeout value to something larger than 90 seconds (default value).