políglota - http keep-alive en la era moderna
biblia políglota complutense polyglot (4)
Entonces, según el autor de haproxy, quién sabe una cosa o dos sobre http:
Keep-alive se inventó para reducir el uso de la CPU en los servidores cuando las CPU eran 100 veces más lentas. Pero lo que no se dice es que las conexiones persistentes consumen mucha memoria sin ser utilizables por nadie, excepto el cliente que las abrió. Hoy en 2009, las CPU son muy baratas y la memoria aún se limita a unos pocos gigabytes por la arquitectura o el precio. Si un sitio necesita mantenerse activo, existe un problema real. Los sitios altamente cargados a menudo desactivan keep-alive para admitir la cantidad máxima de clientes simultáneos. El verdadero inconveniente de no tener keep-alive es una latencia ligeramente mayor para buscar objetos. Los navegadores duplican el número de conexiones concurrentes en sitios que no son de alerta para compensar esto.
(desde http://haproxy.1wt.eu/ )
¿Esto está en línea con la experiencia de otras personas? es decir, sin keep-alive, ¿el resultado apenas es notorio ahora? (es probable que valga la pena señalar que con websockets, etc., una conexión se mantiene "abierta" independientemente del estado de mantener activa de todos modos, para aplicaciones muy receptivas). ¿El efecto es mayor para las personas que están alejadas del servidor, o si hay muchos artefactos para cargar desde el mismo host al cargar una página? (Creo que cosas como CSS, imágenes y JS provienen cada vez más de CDN compatibles con caché).
¿Pensamientos?
(no estoy seguro de si esto es algo de serverfault.com, pero no voy a cruzar la publicación hasta que alguien me diga que lo mueva allí).
En los años transcurridos desde que se escribió esto (y publicado aquí en ), ahora tenemos servidores como nginx, que están ganando popularidad.
nginx, por ejemplo, puede mantener abiertas 10.000 conexiones keep-alive en un solo proceso con solo 2.5 MB (megabytes) de RAM. De hecho, es fácil mantener abiertos miles de conexiones con muy poca RAM, y los únicos límites que alcanzará serán otros límites, como la cantidad de identificadores de archivos abiertos o conexiones TCP.
Keep-alive fue un problema, no por algún problema con la especificación keep-alive en sí, sino por el modelo de escalamiento basado en procesos de Apache y de keep-alives pirateado en un servidor cuya arquitectura no fue diseñada para acomodarlo.
Especialmente problemático es Apache Prefork + mod_php + keep-alives. Este es un modelo en el que cada conexión continuará ocupando toda la memoria RAM que ocupa un proceso de PHP, incluso si está completamente inactiva y solo permanece abierta como una función de mantenimiento. Esto no es escalable. Pero los servidores no tienen que diseñarse de esta manera: no hay una razón en particular para que un servidor mantenga todas las conexiones de mantenimiento activo en un proceso separado (especialmente no cuando cada uno de esos procesos tiene un intérprete completo de PHP). PHP-FPM y un modelo de procesamiento de servidor basado en eventos como el de nginx resuelven el problema de forma elegante.
Actualización 2015:
SPDY y HTTP / 2 reemplazan la funcionalidad keep-alive de HTTP con algo aún mejor: la capacidad no solo de mantener viva una conexión y realizar múltiples solicitudes y respuestas sobre ella, sino también de que se multiplexen, por lo que las respuestas se pueden enviar en cualquier orden , y en paralelo, en lugar de solo en el orden en que fueron solicitados. Esto evita que las respuestas lentas bloqueen las más rápidas y elimina la tentación de que los navegadores mantengan abiertas múltiples conexiones paralelas a un solo servidor. Estas tecnologías destacan aún más las deficiencias del enfoque mod_php y los beneficios de algo así como un servidor web basado en eventos (o al menos, múltiples hilos) acoplado por separado con algo como PHP-FPM.
Hola, ya que soy el autor de esta cita, responderé :-)
Hay dos grandes problemas en sitios grandes: conexiones concurrentes y latencia. La conexión simultánea es causada por clientes lentos que tardan años en descargar contenidos y por estados de conexión inactivos. Esos estados de conexión inactivos son causados por la reutilización de la conexión para recuperar múltiples objetos, conocidos como keep-alive, que aumenta aún más por 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 termina 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 cual muchas personas sugieren usar un tiempo de espera de conservación 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 grandes cargas: si tiene 20000 clientes frente a usted y obtienen un objeto en promedio por segundo, lo hará tener esas 20000 conexiones permanentemente establecidas. 20000 conexiones concurrentes en un servidor de uso general como Apache es enorme, requerirá entre 32 y 64 GB de RAM, dependiendo de qué módulos se carguen, y probablemente no pueda esperar subir mucho más, incluso agregando RAM. En la práctica, para 20000 clientes, incluso puede ver entre 40000 y 60000 conexiones simultáneas en el servidor, ya que 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, caerá 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 el anterior, entonces solo tendrá 0.05 conexiones por cliente, que es solo 1000 conexiones concurrentes para 20000 clientes.
Ahora el tiempo para establecer nuevas conexiones va a contar. Los clientes remotos experimentarán una latencia desagradable. En el pasado, los navegadores solían usar grandes cantidades de conexiones concurrentes cuando el keep-alive estaba desactivado. Recuerdo figuras de 4 en MSIE y 8 en Netscape. Esto realmente habría dividido la latencia promedio por objeto por esa cantidad. Ahora que keep-alive está presente en todas partes, ya no estamos viendo esos números 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 de hoy en día, es más difícil conseguir que los servicios que no se mantienen vivos sean tan receptivos como los que se mantienen vivos. Además, algunos navegadores (por ejemplo, Opera) usan heurística para tratar de utilizar el 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 el doble de rápido que sin keep-alive, pero el próximo acceso es aproximadamente 8 veces más rápido, porque las respuestas son tan pequeñas que solo cuenta la latencia (solo "304" respuestas).
Diría que, idealmente, deberíamos tener algunos parámetros ajustables en los navegadores para hacer que mantengan las conexiones activas entre los objetos recuperados, e inmediatamente soltarlos cuando la página esté completa. Pero no estamos viendo eso desafortunadamente.
Por esta razón, algunos sitios que necesitan instalar servidores de propósito general como Apache en la parte frontal y que tienen que admitir grandes cantidades de clientes generalmente tienen que desactivar keep-alive. Y para obligar a los navegadores a aumentar el número de conexiones, usan múltiples 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 tales sitios prefieren instalar interfaces ligeras como haproxy o nginx, que no tienen ningún problema para manejar decenas a cientos de miles de conexiones simultáneas, permiten mantener vivo el lado del cliente y lo desactivan en el servidor. Lado apache En 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 esta manera, esto proporciona lo mejor de ambos mundos: baja latencia debido a la permanencia activa con tiempos de espera muy bajos en el lado del cliente y baja cantidad 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 equilibrador de carga frontal y el servidor y multiplexando todas las conexiones de clientes sobre ellos. Cuando los servidores están cerca del LB, la ganancia no es mucho más alta que la solución anterior, pero a menudo requerirá adaptaciones en la aplicación para garantizar que no haya riesgo de cruce de sesión entre usuarios debido a la conexión inesperada de una conexión entre múltiples usuarios . En teoría, esto nunca debería suceder. La realidad es muy diferente :-)
Los keep-alives muy largos pueden ser útiles si está utilizando un CDN de "extracción de origen" como CloudFront o CloudFlare. De hecho, esto puede funcionar para ser más rápido que no CDN, incluso si está sirviendo contenido completamente dinámico.
Si lleva mucho tiempo manteniendo aliados de modo que cada PoP básicamente tenga una conexión permanente con su servidor, la primera vez que los usuarios visiten su sitio, pueden hacer un rápido intercambio de protocolo TCP con su PoP local en lugar de un lento saludo con usted. (La luz en sí misma tarda unos 100 ms en llegar a la mitad del mundo a través de la fibra, y establecer una conexión TCP requiere que se pasen tres paquetes. SSL requiere tres viajes de ida y vuelta ).
entendí que tenía poco que ver con la CPU, pero la latencia en la apertura de enchufes repetidos al otro lado del mundo. incluso si tiene ancho de banda infinito, la latencia de conexión ralentizará todo el proceso. amplificado si su página tiene docenas de objetos. incluso una conexión persistente tiene una latencia de solicitud / respuesta, pero se reduce cuando tiene 2 sockets en promedio, uno debe transmitir datos mientras que el otro podría estar bloqueando. Además, un enrutador nunca asumirá que un socket se conecta antes de permitirte escribir en él. Necesita el apretón de manos completo de ida y vuelta. Nuevamente, no pretendo ser un experto, pero así es como siempre lo vi. lo que realmente sería genial es un protocolo totalmente ASYNC (no, no es un protocolo completamente enfermo).