1
votes

Given an ASMX service application hosted on Windows server 2008r2, IIS 7.5, integrated pool, .net 4.0 CLR, 64-bit. It is almost asynchronous and widely use TPL library.

Is it correct to assume that .NET thread-pool minimum worker threads configured to be N forces N worker threads creation at start-up?

I'm expecting this behavior but it does not happen or happens intermittently.

Here are details on configuration: Machine.config section has its attribute 'minWorkerThreads' set to 100, in order to init thread-pool with minimum 100*CPUcount (let's say 400 for 4 core desktop) worker threads.

Just after service application start ThreadPool.GetMinThreads(out minWorkerThreadsCount, out minIoThreadsCount) shows as expected that minWorkerThreadsCount is 400.

Despite this fact Debug 'Threads' window shows only 60 threads the same as Task manager. It seems like thread-pool falls back to the default behavior, but minWorkerThreadsCount is still 400.

Any ideas of what can trigger such behavior or decrease the number of threads at run-time? Allegedly this issue appears when application was build in .NET 4.5 run-time targeting .NET 4.0.

I would appreciate any input.

1
What exactly is your problem? Do you expect more performance if you have 100 times more threads than cores? Or are you just curious? - Alois Kraus
@AloisKraus actually I want to know thread pool behaviour on start-up in order to make right assumptions. Up to your question. Is it more perfomant to have the same number of threads as cores when service makes 1K I/O calls per second on blocking sockets? - Igorium

1 Answers

1
votes

No. It will grow quickly up to that number rather than start with that many threads.

See part of ThreadPool.SetMinThreads I highligted:

Sets the minimum number of threads the thread pool creates on demand, as new requests are made, before switching to an algorithm for managing thread creation and destruction.