23

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/

Thomas
  • 1,970
  • 4
  • 28
  • 59
  • Why do you want to change it? It is hardly ever necessary to alter the minimum number of threads in the threadpool. Msoft have spent alot of time making the threadpool behaviour optimal - why are you different? (edit -not saying you are wrong, just that there might be another solution) – mikelegg Oct 19 '17 at 17:03
  • When you run performance test on this system with large number of concurrent users, the min threads will have have an impact. The number of errors and response time is related to the thread count – Thomas Oct 19 '17 at 17:15

1 Answers1

27

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

Rekshino
  • 6,954
  • 2
  • 19
  • 44
flytzen
  • 7,348
  • 5
  • 38
  • 54
  • Do you mean that it will spawn MinThreads number of threads at once, instead of just one thread? So essentially when it decides it needs a new thread, whatever MinThreads is set to - that number of threads will be created? – Jim Aho Aug 20 '20 at 15:31
  • 4
    @JimAho. No, threads are only created when needed. But the system will create new threads as needed, without waiting for an existing to become free, until MinThreads threads have been created. If an existing thread is free, no new thread will be created. – flytzen Apr 09 '21 at 13:33