En resumen: debería poder lograr del orden de millones de conexiones TCP activas simultáneas y, por extensión, solicitudes HTTP. Esto le indica el rendimiento máximo que puede esperar con la plataforma adecuada con la configuración adecuada.
Hoy, me preocupaba si IIS con ASP.NET admitiría en el orden de 100 conexiones simultáneas (mire mi actualización, espere ~ 10k respuestas por segundo en versiones anteriores de ASP.Net Mono). Cuando vi esta pregunta / respuestas, no pude resistirme a responderme, muchas respuestas a la pregunta aquí son completamente incorrectas.
Mejor caso
La respuesta a esta pregunta solo debe preocuparse por la configuración de servidor más simple para desacoplar las innumerables variables y configuraciones posibles en sentido descendente.
Así que considere el siguiente escenario para mi respuesta:
- No hay tráfico en las sesiones TCP, excepto para los paquetes de mantenimiento (de lo contrario, obviamente necesitaría una cantidad correspondiente de ancho de banda de red y otros recursos informáticos)
- Software diseñado para usar sockets y programación asincrónicos, en lugar de un subproceso de hardware por solicitud de un grupo. (es decir, IIS, Node.js, Nginx ... servidor web [pero no Apache] con software de aplicación diseñado asíncrono)
- Buen rendimiento / CPU / Ram en dólares. Hoy, arbitrariamente, digamos i7 (4 núcleos) con 8GB de RAM.
- Un buen firewall / enrutador para combinar.
- Sin límite virtual / gobernador, es decir. Linux somaxconn, IIS web.config ...
- Sin dependencia de otro hardware más lento, sin lectura desde el disco duro, porque sería el mínimo común denominador y cuello de botella, no la E / S de la red.
Respuesta detallada
Los diseños vinculados a subprocesos síncronos tienden a tener el peor rendimiento en relación con las implementaciones de E / S asíncronas.
WhatsApp obtiene un millón de tráfico CON en una sola máquina con sistema operativo Unix: https://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ .
Y finalmente, este, http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html , entra en muchos detalles , explorando cómo se podrían lograr incluso 10 millones. Los servidores suelen tener motores de descarga TCP de hardware, ASIC diseñados para esta función específica de manera más eficiente que una CPU de propósito general.
Buenas opciones de diseño de software
El diseño de E / S asíncronas diferirá entre los sistemas operativos y las plataformas de programación. Node.js se diseñó teniendo en cuenta el sistema asincrónico . Debería usar Promises al menos, y cuando aparezca ECMAScript 7, async/ await. C # /. Net ya tiene soporte asincrónico completo como node.js. Cualquiera que sea el sistema operativo y la plataforma, se debe esperar que el sistema asincrónico funcione muy bien. Y sea cual sea el idioma que elija, busque la palabra clave "asincrónico", la mayoría de los idiomas modernos tendrán algún soporte, incluso si es un complemento de algún tipo.
¿A WebFarm?
Cualquiera que sea el límite para su situación particular, sí, una granja web es una buena solución para escalar. Hay muchas arquitecturas para lograrlo. Uno es usar un equilibrador de carga (los proveedores de alojamiento pueden ofrecerlos, pero incluso estos tienen un límite, junto con un techo de ancho de banda), pero no estoy a favor de esta opción. Para las aplicaciones de página única con conexiones de larga duración, prefiero tener una lista abierta de servidores entre los que la aplicación cliente elegirá aleatoriamente al inicio y reutilizará durante la vida útil de la aplicación. Esto elimina el único punto de falla (equilibrador de carga) y permite escalar a través de múltiples centros de datos y, por lo tanto, mucho más ancho de banda.
Rompiendo un mito: puertos de 64K
Para abordar el componente de la pregunta con respecto a "64.000", este es un concepto erróneo. Un servidor puede conectarse a muchos más de 65535 clientes. Consulte /networkengineering/48283/is-a-tcp-server-limited-to-65535-clients/48284
Por cierto, Http.sys en Windows permite que múltiples aplicaciones compartan el mismo puerto de servidor bajo el esquema de URL HTTP. Cada uno de ellos registra un enlace de dominio separado, pero en última instancia hay una aplicación de servidor único que envía las solicitudes a las aplicaciones correctas.
Actualización 2019-05-30
Aquí hay una comparación actualizada de las bibliotecas HTTP más rápidas: https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext
- Fecha de prueba: 2018-06-06
- Hardware utilizado: Dell R440 Xeon Gold + 10 GbE
- El líder tiene ~ 7 millones de respuestas de texto plano por segundo (respuestas, no conexiones)
- El segundo, Fasthttp para golang, anuncia 1,5 millones de conexiones simultáneas; consulte https://github.com/valyala/fasthttp
- Los lenguajes líderes son Rust, Go, C ++, Java, C e incluso C # ocupa el puesto 11 (6,9 millones por segundo). Scala y Clojure se clasifican más abajo. Python ocupa el puesto 29 a 2,7 millones por segundo.
- Al final de la lista, anoto laravel y cakephp, rails, aspnet-mono-ngx, symfony, zend. Todo por debajo de 10k por segundo. Tenga en cuenta que la mayoría de estos marcos están diseñados para páginas dinámicas y son bastante antiguos; puede haber variantes más nuevas que aparezcan más arriba en la lista.
- Recuerde que esto es texto sin formato HTTP, no para la especialidad de Websocket: muchas personas que vienen aquí probablemente estarán interesadas en conexiones concurrentes para websocket.