We have a WCF service which handles great amount of requests.
As I discovered, when the number of cuncurrent requests exceed the limit of max cuncurrent connections, the consequent requests will be queued up to be executed later. if time-out happens before these requests have a chance to execute, IIS determins worker process in unresponsive and kills it (or recycles the app pool).
The recycling process takes about one minute and meanwhile the service will be down which is a big problem for us.
Regardless of the cause of timeout and long response time in the code (which we are already working on it), my question is this:
If we define more than one worker-process for this app-pool, what will happen if one of worker-processes is in the same situation? Does IIS recycle the app-pool or the particular worker-process will be killed and other ones keep serving the requests?
Best Answer
If you really, really need the worker process to struggle through it, you can disable the Ping feature in Advanced App Pool properties, which is how I assume IIS is detecting the App Pool has become nonresponsive.
You'd want to be sure that your worker process is going to recover, though, as Ping-based recycling is the seatbelt which means you don't need to get out of bed at 2am if the site hangs...
If the worker process is proactively reporting its own failure to IIS, then it might be unavoidable from the IIS side of things, and you'd need to disable the app framework's own health reporting feature(s).
On the other question/alternative above: if your app is stateless and supports being multi-instanced in a Web Garden (MaxProcesses > 1) then IIS will recycle the worker process which has become nonresponsive, rather than all the WPs belonging to the App Pool - look for System event logs identifying the PID which gets recycled.