He leído varias discusiones sobre el tema y logré entender un poco, pero aún tengo algunos problemas para resolver el problema de rendimiento al convertir de la clase Thread a la clase ThreadPool
Detalles:
Construí un servidor tcp, con fines educativos (la tarea no debe ser con métodos asíncronos), que acepta conexiones de clientes y crea un nuevo hilo para cada cliente. Con este método, la aplicación se ejecuta durante menos de un segundo, pero cuando decidí pasar a una solución de siguiente nivel, como un grupo de subprocesos, mi rendimiento se redujo a 40-50 segundos para solo cien clientes y solo envié un búfer de 2048 bytes, recíbalo y cerca.
Los primeros 12 subprocesos son muy rápidos, muy probablemente porque mi CPU tiene 6 núcleos y 12 subprocesos y después de eso, los subprocesos comienzan a experimentar un retraso. Estoy abierto a ideas de solución y enfoque de estructura.
Código del servidor:
public void OnSocketReceive() { while (!this.exitServer) { if (!tcpListener.Pending()) { Thread.Sleep(10); continue; } TcpClient client = tcpListener.AcceptTcpClient(); IManageConnectedUser chatLogic = new ManageConnectedUser(connections, welcomeMessage); //Thread clientThread = new Thread(new ParameterizedThreadStart(chatLogic.OnClientConnection)); //clientThread.Start(client); ThreadPool.QueueUserWorkItem(chatLogic.OnClientConnection, client); }Más aclaración
Con mucho, con la depuración que he hecho y las discusiones que he leído, llegué a la conclusión de que el problema es el código de bloqueo en la función OnClientConnection y más específicamente en la función interna que es stringCreateHandler. Donde recibo este error: System.Threading.ThreadInterruptedException: el hilo se interrumpió desde un estado de espera en la línea 39, que es Thread.Sleep (10);
public string stringCreateHandler(TcpClient client) { StringBuilder sb = new StringBuilder(); try { do { if (client.Available > 0) { while (client.Available > 0) { char ch = (char)client.GetStream().ReadByte(); if (ch == '\r') { continue; } if (ch == '\n') { return sb.ToString(); } sb.Append(ch); } } Thread.Sleep(10); } while (true); } catch (Exception e) { Console.WriteLine(e); throw; } }Revisé el resto del código. No creo que haya más código de bloqueo, pero doy un enlace al proyecto https://github.com/nikolaymih/Chat-Project/tree/master/ChatProjectNewThreads La única diferencia existe la clase Thread en lugar de ThreadPool, pero esto es solo para orientación
Mirando su proyecto completo, creo que su problema es que OnClientConnection es de larga duración: no volverá hasta que se cierre esa conexión, y dado que esta es una "aplicación de chat", las conexiones permanecen abiertas y no se cierran rápidamente.
Como ha visto, ThreadPool comienza con una cantidad de subprocesos inactivos y agregará subprocesos según sea necesario a una velocidad de aproximadamente uno cada 500 ms (aunque esto es un detalle de implementación). Esto normalmente no es un problema: se supone que no debe usar ThreadPool para tareas de ejecución muy larga que nunca regresan y que atan hilos para siempre. Sin embargo, dado que su método OnClientConnection no regresa durante mucho tiempo, solo está agarrando y acaparando subprocesos de ThreadPool y obligando a ThreadPool a seguir expandiéndose.
Si desea utilizar un subproceso por cliente, probablemente sea mejor que cree un nuevo subproceso de ejecución prolongada por cliente. Sin embargo, esto es bastante derrochador: tendrás un montón de subprocesos dando vueltas sin hacer mucho. Es mejor tener una pequeña cantidad de subprocesos que constantemente procesan mensajes de un gran grupo de clientes. Es posible diseñar esto usted mismo, pero es mucho más fácil simplemente usar las capacidades async/await de TcpListener y NetworkStream .