Idle Time-out Settings for an Application Pool - iis

can someone explain for me this sentence from msdn ?
Idle time-out can be helpful in the following situations:
The server has a heavy processing load.
is the idle timeout for the w3wp.exe process or each user that's connected to the website has a nested process inside the w3wp and this is the idle time for this nested process? if it's the idle process for w3wp as a whole , then what does msdn sentence mean??

It prevents a application pool worker process from hanging around when no users are hitting the web pages hosted by the worker process. When the users stop hitting the web site for a while, IIS stops the process.
This can be annoying if you have an expensive setup/teardown process for the application, such as populating a cache.

The idle timeout is per application pool. You can observe the running pools as well as in IIS in VS by Tools > Attach to Process then I click the Process column header to bring any running w3wp.exe's to the top.
You can set the timeout for each app pool in IIS7+ in Advanced Settings... Process Model section.

Related

W3 service stops, but w3wp.exe are still running for a number of seconds

I stopped the World Wide Web Publishing Service - normally this service won't stop until all of the w3wp.exe processes shut down. But I am now seeing a strange behavior where the service actually stops quickly -- but the w3wp.exe is still there, and those processes end after a number of seconds (10-15 seconds?) Did something change in the behavior of IIS?
The default ShutdownTimeLimit value is 90 seconds. application pool needs time to fully shut down, as any requests currently processing when the shutdown is initiated and needs to be given a certain amount of time to complete.
if it takes too long time to shut down then you could troubleshoot the application pool by capturing a memory dump of the w3wp.exe process in which the application pool is running, when the shutdown problem is occurring.
For more information on capturing memory dumps of IIS processes, see Debug Diagnostics Tool v1.2 is now available.

How to monitor IIS worker process using Windows performance monitor

I have an asp.net mvc application deployed in IIS. Sometimes its application pool worker process hangs so I would like to know if there is a way to monitor a specific IIS worker process using windows performance monitor? If so, what indicators I have to monitor?
As far as I know, we could add counter in the process monitor to figure out the Process identifier of the process.
You could right click the performance window and select counter.
Then you could choose the was_w3wp and select the process id w3wp process.

IIS 8 Application pool recycle vs SignalR 2.3.0

I have a website in IIS 8.5.9600.16384, we communicate with thousands of mobile devices through cyclic synchronisation and through SignalR 2.3.0.
This morning we had an application pool reset during working hours, which caused the SignalR to call "OnReconnect" of all our mobile devices at the same time.
I though that IIS started new processes first and then killed the old, not having downtime.
Can somebody tell me exactly what happens when IIS recycles it's application pool on the SignalR side? And in which cases can there be a connection downtime? (ex : if the server is busy?)
Edited : The application pool was recycled by IIS because of the "time limit". The IT team will change this setting so that the application pools reset every day at night time when it will have a lower impact on our applications.
A worker process with process id of '8720' serving application pool 'DefaultAppPool' has requested a recycle because the worker process reached its allowed processing time limit.
Also confirmed that disallowOverlappingRotation is not set to True. Any hint would help.
A few years later, I'm still getting some problems with the application pool recycle and SignalR. We are occasionally seeing thousands of re-connections of SignalR while the application pool recycle occurs, opening more than 60k TCPIP ports and causing a crash in IIS.
We managed to have it run "okay" for quite some time but it still crashes. Any hint would help. thanks
I'd first identify how IIS was reset. If you experienced a crash or performed an IISReset, the processes would be down before a new one stood back up. If on the other hand you configured AppPool recycling, then the overlapping processes should occur as you mention. I would check the System Event Log for recycling messages. Note that not all recycle reasons are logged by default.
You may also check to make sure disallowOverlappingRotation is not set to True.
Specifies whether the WWW Service should start another worker process to replace the existing worker process while that process is shutting down. The value of this property should be set to true if the worker process loads any application code that does not support multiple worker processes.
https://learn.microsoft.com/en-us/iis/configuration/system.applicationhost/applicationpools/add/recycling/

Web Api Requests Queueing up forever on IIS (in state: ExecuteRequestHandler)

I'm currently experiencing some hangs on production environment, and after some investigation I'm seeing a lot of request queued up in the worker process of the Application Pool. The common thing is that every request that is queued for a long time is a web api request, I'm using both MVC and Web API in the app.
The requests are being queued for about 3 hours, when the application pool is recycled they immediately start queueing up.
They are all in ExecuteRequestHandler state
Any ideas for where should I continue digging?
Your requests can be stalled for a number of reasons:
they are waiting on I/O operation e.g database, web service call
they are looping or performing operations on a large data set
cpu intensive operations
some combination of the above
In order to find out what your requests are doing, start by getting the urls of the requests taking a long time.
You can do this in the cmd line as follows
c:\windows\system32\inetsrv\appcmd list requests
If its not obvious from the urls and looking at the code, you need to do a process dump of the w3wp.exe on the server. Once you have a process dump you will need to load it into windbg in order to analyze what's taking up all the cpu cycles. Covering off windbg is pretty big, but here's briefly what you need to do:
load the SOS dll (managed debug extension)
call the !runaway command
to get list of long running threads dive into a long running thread
by selecting it and calling !clrstack command
There are many blogs on using windbg. Here is one example. A great resource on analyzing these types of issues is Tess Ferrandez's blog.
This is a really long shot without having first hand access to your system but try and check the Handler mappings in IIS Manager gui for your WebApi. Compare it with IIS settings of your DEV or any other Env where it works.
IF this isnt the issue then do a comparison of all other IIS settings for that App.
Good luck.

How to Diagnose App Pool Issues

I have a large web app that runs on our two live servers. Part of our server side C# code calls a third party app to do a task for us.
That task works most of the time, but at a certain point it stops working until the AppPool is recycled.
This all happens in w3wp.exe, so I can see it running in process monitor like this (when it is not working),
Thread Create
Access the file PreviewGenerator.exe
Hive unloaded (this is the registry)
Thread Exit
And like this when it is working,
Thread Create
Access the file PreviewGenerator.exe
Process Start
Does heaps of stuff with PreviewGenerator.exe including reading / writing / registry, etc.
Process Exit
Hive unloaded
Thread Exit
How can I debug what is going on in my AppPool and why starting a separate process is not working some of the time?
I found the best thing to do was to create a separate app pool for my application in IIS and set an upper limit for the amount of RAM it could use. Also I found it useful to turn on the 'Generate Recycle Event Log Entry' items under the app pool settings.
You can then go to the system event log and filter out the items with a source of 'WAS' to understand what is going on in the app pools, when they are restarting and when they stop from being idle etc.
I think the main problem in our case is that the IIS box was running out of memory. Tuning the app pools and adding some extra RAM seems to have solved it.

Resources