Hola, ya que soy el autor de esta cita, responderé :-)
Hay dos problemas importantes en los sitios grandes: conexiones simultáneas y latencia. La conexión simultánea se debe a clientes lentos que tardan mucho en descargar contenidos y a estados de conexión inactivos. Esos estados de conexión inactivos se deben a la reutilización de la conexión para recuperar varios objetos, lo que se conoce como mantener vivo, que se incrementa aún más con la latencia. Cuando el cliente está muy cerca del servidor, puede hacer un uso intensivo de la conexión y asegurarse de que casi nunca esté inactiva. Sin embargo, cuando finaliza la secuencia, a nadie le importa cerrar rápidamente el canal y la conexión permanece abierta y sin usar durante mucho tiempo. Esa es la razón por la que muchas personas sugieren usar un tiempo de espera de vida muy bajo. En algunos servidores como Apache, el tiempo de espera más bajo que puede establecer es de un segundo y, a menudo, es demasiado para soportar cargas elevadas: si tiene 20000 clientes frente a usted y obtienen un promedio de un objeto por segundo, tendrá esas 20000 conexiones establecidas permanentemente. 20000 conexiones simultáneas en un servidor de propósito general como Apache es enorme, requerirá entre 32 y 64 GB de RAM dependiendo de los módulos que se carguen, y probablemente no pueda esperar ir mucho más alto incluso agregando RAM. En la práctica, para 20000 clientes, es posible que vea entre 40000 y 60000 conexiones simultáneas en el servidor porque los navegadores intentarán configurar de 2 a 3 conexiones si tienen muchos objetos para recuperar. y probablemente no pueda esperar ir mucho más alto incluso agregando RAM. En la práctica, para 20000 clientes, incluso puede ver entre 40000 y 60000 conexiones simultáneas en el servidor porque los navegadores intentarán configurar de 2 a 3 conexiones si tienen muchos objetos para recuperar. y probablemente no pueda esperar ir mucho más alto incluso agregando RAM. En la práctica, para 20000 clientes, incluso puede ver entre 40000 y 60000 conexiones simultáneas en el servidor porque los navegadores intentarán configurar de 2 a 3 conexiones si tienen muchos objetos para recuperar.
Si cierra la conexión después de cada objeto, la cantidad de conexiones simultáneas disminuirá drásticamente. De hecho, se reducirá en un factor correspondiente al tiempo promedio para descargar un objeto por el tiempo entre objetos. Si necesita 50 ms para descargar un objeto (una foto en miniatura, un botón, etc.), y descarga en promedio 1 objeto por segundo como se indicó anteriormente, entonces solo tendrá 0.05 de conexión por cliente, que es solo 1000 conexiones concurrentes para 20000 clientes.
Ahora va a contar el tiempo de establecer nuevas conexiones. Los clientes muy remotos experimentarán una latencia desagradable. En el pasado, los navegadores solían utilizar grandes cantidades de conexiones simultáneas cuando Keep-Alive estaba deshabilitado. Recuerdo cifras de 4 en MSIE y 8 en Netscape. Esto realmente habría dividido tanto la latencia promedio por objeto. Ahora que Keep-Alive está presente en todas partes, ya no vemos números tan altos, porque hacerlo aumenta aún más la carga en los servidores remotos y los navegadores se encargan de proteger la infraestructura de Internet.
Esto significa que con los navegadores actuales, es más difícil conseguir que los servicios que no son de mantenimiento de vida sean tan receptivos como los de mantenimiento de vida. Además, algunos navegadores (por ejemplo: Opera) usan heurística para intentar usar pipelinining. La canalización es una forma eficiente de usar Keep-Alive, porque casi elimina la latencia al enviar múltiples solicitudes sin esperar una respuesta. Lo probé en una página con 100 fotos pequeñas, y el primer acceso es aproximadamente dos veces más rápido que sin Keep-Alive, pero el siguiente acceso es aproximadamente 8 veces más rápido, porque las respuestas son tan pequeñas que solo cuenta la latencia (solo Respuestas "304").
Yo diría que, idealmente, deberíamos tener algunos parámetros optimizables en los navegadores para que mantengan vivas las conexiones entre los objetos recuperados y que lo suelten inmediatamente cuando la página esté completa. Pero, lamentablemente, no estamos viendo eso.
Por esta razón, algunos sitios que necesitan instalar servidores de propósito general como Apache en la parte frontal y que deben admitir una gran cantidad de clientes generalmente tienen que deshabilitar Keep-Alive. Y para obligar a los navegadores a aumentar el número de conexiones, utilizan varios nombres de dominio para que las descargas se puedan paralelizar. Es particularmente problemático en sitios que hacen un uso intensivo de SSL porque la configuración de la conexión es aún mayor, ya que hay un viaje de ida y vuelta adicional.
Lo que se observa más comúnmente hoy en día es que dichos sitios prefieren instalar interfaces ligeras como haproxy o nginx, que no tienen problemas para manejar decenas a cientos de miles de conexiones simultáneas, habilitan el mantenimiento de la vida en el lado del cliente y lo deshabilitan en el Lado de Apache. Por este lado, el costo de establecer una conexión es casi nulo en términos de CPU, y no se nota en absoluto en términos de tiempo. De esa manera, esto proporciona lo mejor de ambos mundos: baja latencia debido a mantener vivo con tiempos de espera muy bajos en el lado del cliente y bajo número de conexiones en el lado del servidor. Todos están felices :-)
Algunos productos comerciales mejoran aún más esto reutilizando las conexiones entre el balanceador de carga frontal y el servidor y multiplexando todas las conexiones de los clientes a través de ellos. Cuando los servidores están cerca del LB, la ganancia no es mucho mayor que la de la solución anterior, pero a menudo requerirá adaptaciones en la aplicación para garantizar que no haya riesgo de cruce de sesiones entre usuarios debido al intercambio inesperado de una conexión entre múltiples usuarios. . En teoría, esto nunca debería suceder. La realidad es muy diferente :-)