One common problem we see is the blocking of .NET ThreadPool threads. This blocking can lead to ThreadPool thread starvation, and sometimes even deadlocks.
This is especially true as of late with more and more folks using asynchronous code, and trying to convert existing, synchronous methods into async, but leaving parts of the code sync.
I don't go into the above scenarios in this post; but, some folks want to change the ThreadPool defaults regarding the number of maximum or minimum worker and/or IO threads to troubleshoot a problem or test application behavior with different settings. There is conflicting information out there on how to change the ThreadPool settings for an ASP.NET 4.x web app, so the purpose of this post is to cover how to make those changes correctly.
NOTE: We generally don't recommend modifying the CLR TP thread counts, as the defaults work for the vast majority of scenarios.
If you want to change the ThreadPool settings in an ASP.NET application, you have two choices:
For #1, here's how the processModel section is declared in the machine.config:
<section name="processModel" type="System.Web.Configuration.ProcessModelSection, System.Web, Version=22.214.171.124, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" allowDefinition="MachineOnly" allowLocation="false"/>
allowDefinition="MachineOnly" means this section/element can only be configured in the machine.config, and not any other downlevel config. The allowLocation="false" means this section cannot be placed in a <location> tag.
This means if you try to change the processModel element in an app's web.config or try to modify a copy of one inside a location tag, you'll receive an error.
A modifed processModel element could look like this:
<processModel autoConfig="false" maxWorkerThreads="100" minWorkerThreads="2" maxIoThreads="100" minIoThreads="2" />
For any explicit thread counts to be honored, you'd need to set autoConfig="false" - by default it's set to true.
Some folks have tried placing a modified processModel element into a separate .config file, then configuring the IIS host's application pool's CLRConfigFile property to load that file. (This feature is described here.) This does not work for modifying the .NET ThreadPool, and will not modify the actual <processModel> settings that get pulled-in.
This also means modifying the Aspnet.config file that exists in the Framework\[version]\ directory to add a system.web\processModel element will not work. We are limited to changing this element in the machine.config only.
But wait, doesn't editing the machine.config affect the entire server? Yes, it does! Granted, we're only editing the system.web section, so only apps that consume that section will be modified. Still, this is a reason to not make the change here, even though you can.
That pretty much leaves it up to the application itself, via option #2 above. You can make the change anywhere in the app (even on an aspx page or an MVC View, for example) and it will stick for the rest of the app's lifetime, or until it gets changed again. When the application pool/domain/etc. is recycled, it will pull the defaults until your call to modify the TP is made again. (I'll make another post to demonstrate these defaults.)
One idea is to use the app's *.config (or wherever you're storing app settings) to store your desired changes, then pull those values into the app and apply them early-on in the application's lifetime.
Again, we don't recommend modifying the ThreadPool counts unless absolutely necessary. This post was just to show how to make the changes so they stick.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.