Safe values for ThreadPool.SetMaxThreads

[Louis Somers]

Hi,

Can anyone point me to a good guideline for setting the worker and
CompletionPort values on the static ThreadPool? I often feel like
shooting in the dark when tweaking them on my laptop, not knowing what
effect they will have in the wild.

I'm aware that it strongly depends on what the worker threads are
actually doing, however I'd like to see rough guidelines anyway setting
forth ratios for:

Console Applications
Windows Forms Applications
Windows Services
(Webapps are probably not relevant since IIS determines what's best.)

Against scenarios like:

Heavy computing,
Heavy disk traffic
Heavy Database Querying

I assume that the number of CompletionPorts should in most cases be
larger than the number of worker threads? But at what ratios?

I'd also like to see a rough overview of what parts of the .Net
framework make use of the ThreadPool and how intense.

for:
System.IO.[File/Directory] ...
System.Net.Sockets ...

Any pointer to a good source of info would be appreciated!

Cheers,
Louis

 

[Louis Somers]

Peter Duniho schreef:

It seems to me that, while written some time ago, this article is still
relevant and useful:
http://msdn.microsoft.com/en-us/library/ms973903.aspx

The short answer is, leave the ThreadPool settings alone unless you are
certain they have to be changed.

As far as the specific things you've asked:

-- You can't generalize thread usage according to
console/forms/service/etc.
-- You can do very little generalization according to computing/disk
i/o/database i/o/etc.
-- In the ThreadPool, there two categories of threads:
general-purpose worker threads, and i/o completion port threads. There
is no reliable target ratio between those two categories.

The fact is, unless you have identified some specific performance
problem, there's very little benefit in messing around with the
ThreadPool settings. And by "identified", I mean you have stated a
performance goal, have measured your performance and found that it
doesn't meet that goal, and you have profiled the activity of your
application and determined that the exact cause of the performance
problem is incorrect settings for the ThreadPool.

This almost never happens.

Depending on how your own code is using the ThreadPool, you may or may
not find it beneficial to restrict your own usage of the ThreadPool.
For example, if you are a heavy CPU user, with those computational tasks
being done on the ThreadPool, you will probably find it better to not
submit more tasks to the ThreadPool at any given time than there are CPU
cores.

For i/o-based processing, you have a lot more leeway, because once a
thread has been created, if it's just sitting there waiting on some i/o,
it's not reducing performance for other threads. And of course, the
ThreadPool itself will prevent the cost of creating a thread from
becoming a big problem, since it won't allocate new threads to service
queued work items very fast (two threads per second is the current
behavior, if I recall correctly).

Note that in either case, if you find a need to restrict how many active
ThreadPool threads you've caused to exist, the best and most appropriate
solution is to maintain your own restrictive access to the ThreadPool
rather than trying to limit the ThreadPool itself. Too many other
components within .NET use the ThreadPool, and messing around with the
ThreadPool settings can easily have unintended and negative consequences.

Pete

Thanks for your answer Peter,

In my case I've always had a performance benefit by decreasing the
number of threads down to between 3 and 5 (on my dualcore laptop). These
threads do allot of database querying and disk IO, (not much CPU).

I don't like the idea of throttling the number of threads thrown into
the pool, in my eyes it should be a feature of the pool to throttle
execution. The more I think about it, writing my own thread pool might
be a better solution after all, a non-static one so I can have instances
for different tasks which can be throttled individually.

Cheers,
Louis