IIS - Thread pool setting machine.config vs web.config

Question

I am running a ASP.NET 4.5 Web API application on IIS 8.5. Under worker process, I am seeing certain request are queued up by IIS and are never being served. This could be a memory leak issue. I am still investigating. During investigation I read about thread pool settings.

The article talks about Recommended Threading Settings for Reducing Contention. The article says make these changes in machine.config. My question is can I make these changes in web.config ?

Do we have any other recommendation for fixing he queuing issue.

Answer 1

Machine.config specify the configuration for all .Net applications in this windows instance. Web.config specific the configuration for specific application.

If this issue only happen in single IIS web application, you could specify the configuration in Web.config. Otherwise, it is suggested to set them in Machine.config.

In my experience, Your problem should be an application pool hang or low performance issue if request get stuck in queue. First of all, please check whether any error message was logged in IIS application or system event log.

To troubleshooting performance issue, please try to capture dump file with Procdump or debug diagnostic tool.

We need to check these managed stack traces via these dump file. So that we got to know which method or request are getting slow or hung.

With WINDBG mex extension, we will know：

1. how many request are being processed
2. How's the status of each thread
3. Is there any thread get frozen or dead locked
4. If there is a deadlock, Which thread is get locked and what's the address of your dead lock.

If we need to know which configuration or solution should be applied in your server, find the root cause or characteristic is also necessary.

If you don't know how to Analyze dump file, Debug diagnostic analysis tool or WINDBG analyze -v command would help.

Answer 2

It's something in your application code that is hanging or just running too long.

The request monitor in IIS Manager shows all currently running requests - not just requests that have not been served yet. I confirmed this by running a project in Visual Studio that I have setup to debug in IIS. I set a breakpoint in Visual Studio and initiated a request in my browser. When it hit that breakpoint, the request monitor showed that request and the time kept climbing as long as I did not continue execution of the code.

While sitting at the breakpoint, the "State" I saw in IIS Manager was "ExecuteRequestHandler", so if that's the state you see, then the request is surely being served by your application, and it's your application being slow.

If it only happens with one specific API call, you can look through your code for possible deadlocks or long-running queries. Jokies' answer might help you pinpoint where and why easier (maybe). If it makes SQL queries, you could also look at pending queries on your SQL server to see what it's doing.

(Side note: I didn't even know that request monitor existed before this, so this was interesting to look into!)

Update: You can enabled Failed-Request Tracing in IIS to hunt down exactly where it's stalling. Create a timed rule (log a trace when requests take longer than x seconds). The only downside is that it has to change your web.config to enable this, so it'll recycle your app pool, which may or may not restrict when you can do this.

There is more information in this article about tracing long-running requests, including that you can modify your code to use Trace.Write to write information from your code into the traces that IIS picks up.