Estoy tratando de averiguar exactamente qué impacto tiene ThreadPool.SetMinThreads .
Según la documentación oficial dice
Establece la cantidad mínima de subprocesos que crea el grupo de subprocesos a pedido, a medida que se realizan nuevas solicitudes, antes de cambiar a un algoritmo para administrar la creación y destrucción de subprocesos.
Según tengo entendido, como desarrollador, se supone que debo tener control sobre el mecanismo sobre cómo hacer girar nuevos subprocesos a pedido, de modo que se creen y esperen en estado inactivo, en situaciones en las que, por ejemplo, espero que llegue una carga de solicitud. en tiempo especifico.
Y esto es exactamente para lo que inicialmente pensé que el método SetMinThreads está diseñado.
Pero cuando comencé a jugar con él, obtuve resultados realmente extraños.
Así que tengo mi aplicación ASP.NET .NET5, y en la acción del controlador tengo un código como este: ThreadPool.SetMinThreads(32000, 1000);
Y, por supuesto, espero intuitivamente que el tiempo de ejecución cree 32 000 subprocesos de trabajo y 1000 subprocesos io para mí.
Y cuando hago eso, y luego llamo a otro método: Process.GetCurrentProcess().Threads para obtener todos los subprocesos del proceso e imprimir estadísticas sobre ellos, obtengo algo como esto
Standby - 17 Running - 4Pensé que tal vez la aplicación necesita algo de tiempo para generar nuevos hilos, así que probé diferentes retrasos, 1 minuto, 5 minutos y 10 minutos.
Pero el resultado siempre es el mismo, obtengo 15-20 Standby y 2-4 en Running .
Entonces viene una pregunta lógica: ¿qué está haciendo exactamente el método SetMinThreads ? La descripción proporcionada por MSDN no parece muy útil.
Y otra pregunta lógica: ¿qué pasaría si quisiera obligar a dotnet a girar 32K de nuevos subprocesos en estado inactivo? ¿Dotnet proporciona algún mecanismo para ello?
ThreadPool.SetMinThreads establece el número mínimo de subprocesos que ThreadPool crea instantáneamente bajo demanda . Esa es la frase clave, y de hecho es bastante poco intuitiva. El ThreadPool actualmente¹ (.NET 5) funciona en dos modos:
Cuando llega una nueva solicitud de trabajo y todos los subprocesos del grupo están ocupados, cree instantáneamente un nuevo subproceso para satisfacer la solicitud.
Cuando llega una nueva solicitud de trabajo y todos los subprocesos del grupo están ocupados, ponga en cola la solicitud y espere 1 segundo antes de crear un nuevo subproceso, con la esperanza de que, mientras tanto, uno de los subprocesos de trabajo complete su trabajo actual y estará disponible para atender la solicitud en cola.
ThreadPool.SetMinThreads establece el umbral entre estos dos modos. No le da control sobre la cantidad de subprocesos que están vivos en este momento. Lo cual no es muy satisfactorio, pero es lo que es. Si desea forzar a ThreadPool a crear 1000 subprocesos al instante, también debe enviar una cantidad igual de solicitudes de trabajo, además de llamar a ThreadPool.SetMinThreads(1000, 1000) . Algo como esto debería hacer el truco:
ThreadPool.SetMinThreads(1000, 1000); Task[] tasks = Enumerable.Range(0, 1000) .Select(_ => Task.Run(() => Thread.Sleep(100))) .ToArray(); Sinceramente, no creo que nadie haga eso. La creación de un nuevo Thread es bastante rápida en tiempo humano (requiere alrededor de 0,25 milisegundos por subproceso en mi PC), por lo que para un sistema que recibe solicitudes de humanos, la sobrecarga de crear un subproceso no debería tener ningún impacto medible. Por otro lado, 0,25 mseg es un eón en el tiempo de la computadora, cuando desea que un subproceso haga una pequeña cantidad de trabajo (en el rango de nanosegundos), como agregar algo en List<T> . Es por eso que se inventó ThreadPool en primer lugar: para amortizar la sobrecarga de la creación de subprocesos para cargas de trabajo pequeñas pero numerosas.
Tenga en cuenta que la creación de un Thread nuevo también tiene un costo de memoria, que generalmente es más significativo que el costo del tiempo: cada subproceso requiere al menos 1 MB de RAM para su pila. Por lo tanto, la creación de 32 000 subprocesos vinculará 32 GB de memoria solo para espacio de pila. Esto no es muy eficiente. Es por eso que en los últimos años la programación asíncrona se ha vuelto tan prominente en el desarrollo web del lado del servidor, porque permite hacer más trabajo con menos subprocesos.
¹ No hay nada que impida que los ingenieros de Microsoft cambien/modifiquen la implementación de ThreadPool en el futuro. AFAIK esto ya ha sucedido al menos una vez en el pasado.