ThreadPool SetMinThreads - the impact of setting i

问题:

I am trying to understand the impact of setting ThreadPool.SetMinthreads. I have multiple virtual applications running in one Azure App Service. My understanding is that all these virtual applications will share the App Pool, and will have only one worker process (Assuming the App Pool's max worker process will be 1).

I have the below two questions.

1. In this setup, if I set ThreadPool.SetMinThreads to let's say 100 worker threads and IO threads, can I safely assume that each app domain will have 100 worker threads and 100 IO threads when it is loaded? To be precise, the ThreadPool.SetMinThreads applies within the AppDomain, or Worker Process or App Pool? What is the scope of ThreadPool?
2. I also assume there is no limitation on the max threads the system can spawn as it is determined by the underlying host's capacity. This means, if I do not explicitly set ThreadPool.SetMaxThreads, the system will spawn new threads and will continue to do it if there is a continuous load till CPU/Memory spikes to the max. I am basing on the below statement to support my assumption:

Process and threads, for example, require physical memory, virtual memory, and pool memory, so the number of processes or threads that can be created on a given Windows system is ultimately determined by one of these resources, depending on the way that the processes or threads are created and which constraint is hit first. https://blogs.technet.microsoft.com/markrussinovich/2009/07/05/pushing-the-limits-of-windows-processes-and-threads/

回答1:

The MinThreads governs how many worker threads will be spawned without a delay.

Whenever you do something that requires a thread from the thread pool (whether worker or IOCP pool), the system will first see if there is a free thread.

If not, it looks to see how many threads are currently spawned. If that number is less than MinThreads, it immediately spawns a new thread. Otherwise it waits a short time, usually around 300-500ms, though that is system dependent. If there is still no free thread, it will then spawn a new thread.

Of course, this all is still limited by MaxThreads.

All that said, IIS is very good at figuring out a sensible number based on your machine and in most cases you are best to leave it alone; if you are just worried about serving requests then I wouldn't touch it personally. If, on the other hand, you are spawning a lot of background tasks yourself then it may be sensible. I'd strongly encourage you to measure it before you actually make changes.

Though... Setting MinThreads to 100 is rarely harmful, especially as the system will only start the number of threads it actually needs anyway