Este contenido se ha discutido muchas veces en cnblogs. Leí información en los últimos dos días, vi algunos indicadores de rendimiento simples y los discutí con todos.
Socket + Hilos/ThreadPool
Rendimiento aproximado: menos de 1500 conexiones.
Implementación: aceptar un socket y dejar que un hilo lo administre. Es relativamente estúpido, pero también es más efectivo porque es un método sincrónico y es muy conveniente de controlar. Lo más avanzado es entregarlo a un grupo de subprocesos para su administración. El sistema aloja automáticamente el grupo de subprocesos, lo que ahorra tiempo en los subprocesos generales. Para proyectos pequeños en general, esto es completamente suficiente y el desarrollo es simple. Pero tenga en cuenta que si varios sockets ocupan subprocesos en el grupo de subprocesos durante mucho tiempo y hay muchas otras conexiones, es fácil recibir un mensaje que indique que no tiene suficientes subprocesos para usar. Jaja, es una buena idea dejar que Socket haga menos trabajo y tome menos tiempo. Cambiar a una CPU más rápida es una buena manera. Además, si existen algunos componentes de grupo de subprocesos de terceros mejores, también puede optar por utilizarlos, como SmartThreadPool.
Zócalo+Seleccionar
Rendimiento aproximado: el rendimiento disminuye después de más de 1500 conexiones.
Implementación: Select es un modelo muy utilizado. Es sondear uno o más Sockets en la función de bloqueo y colocar el Socket para procesar en una IList. Cuando se complete el sondeo de selección, procesaremos el Socket en esta IList nosotros mismos. Para un uso específico, consulte MSDN. No se puede decir que la eficiencia de Select sea alta, porque cuando hay muchos Sockets para procesar en la cola, procesar los últimos Sockets equivale a atravesar todos los Sockets anteriores, lo cual es muy antieconómico.
Zócalo+Asíncrono
Rendimiento aproximado: alrededor de 7500 conexiones de clientes
Implementación: BeginXXXX, EndXXXX, todos lo conocemos. En el análisis final, el Socket asíncrono todavía usa la tecnología de grupo de subprocesos y utiliza el grupo de subprocesos para manejar IO asíncrono. Esto plantea otra pregunta: ¿qué método de implementación se utiliza para el grupo de subprocesos de .NET? He visto a alguien decir antes que el grupo de subprocesos de .NET se implementa mediante puertos de finalización. No sé si esto es correcto. de la información que encontré (espero que un amigo pueda decirme esto). El socket asíncrono es mucho más complicado que el flujo de procesamiento de programas síncrono, y el control de las funciones de devolución de llamada asíncronas no es tan intuitivo como el método síncrono. Pero una cosa que creo que debe tenerse en cuenta es que la función de devolución de llamada debe usarse a la ligera y no debe manejar demasiadas transacciones. El procesamiento de los datos transferidos debe dejarse en manos de otros subprocesos.
IOCP (puerto de finalización)
Rendimiento aproximado: alrededor de 20 000 ~ 50 000 conexiones de clientes
. Implementación: hay algunos pseudo-IOCP en .NET. No he visto ningún ejemplo de SOCKET abierto implementado con estos pseudo-IOCP. Las 20.000 ~ 50.000 conexiones de clientes de las que hablo se refieren a la situación de desarrollo en C++. En este caso, las tecnologías básicas que deben utilizarse incluyen grupos de memoria, algoritmos de consulta, etc.
No hay información para comprobar el número máximo de conexiones que puede lograr el pseudo-IOCP. Si alguien lo sabe, puede comentarlo. Además, muchos de los datos mencionados anteriormente están extraídos de cierta información. No lo he probado yo mismo, solo lo presento para discutirlo con todos. Creo que un programa de servidor de alto rendimiento puede requerir tecnología que no solo es qué modelo usar, sino también muchos detalles a los que se debe prestar atención, como el procesamiento de la memoria, qué algoritmo usar, etc. Sólo en términos de costo de software definitivamente habrá inversión en hardware.