En cualquier instalación predeterminada, Apache 2 viene con keepAlive apagado, pero mirando a otro servidor, el módulo keepAlive estaba encendido.
Entonces, ¿cómo sé si keepAlive es adecuado para mí? ¿Dónde puedo encontrar algunos buenos ejemplos sobre cómo configurar esto?
Respuestas:
Ya hay 2 buenas respuestas, pero quizás el tema más importante de la vida real aún no se menciona.
En primer lugar, el OP podría querer leer las 2 respuestas anteriores y esta pequeña publicación de blog para comprender qué son los keepalives. (El autor no explica por qué TCPI / IP se vuelve "más rápido" cuanto más tiempo se abre la conexión. Es cierto, las conexiones más duraderas se benefician del escalado de la ventana IP , pero el efecto no es significativo a menos que los archivos sean grande, o el producto de retraso de ancho de banda es inusualmente grande).
El gran argumento contra HTTP Keepalive cuando se usa Apache es que bloquea los procesos de Apache. Es decir, un cliente que usa keepalives evitará que 'su' proceso de Apache sirva a otros clientes, hasta que el cliente cierre la conexión o se agote el tiempo de espera. En el mismo lapso de tiempo, esta instancia de Apache podría haber servido muchas otras conexiones.
Ahora, una configuración de Apache muy común es Prefork MPM y un intérprete PHP / Perl / Python, y el código de la aplicación en el idioma mencionado. En este caso, cada proceso de Apache es "pesado" en el sentido de que ocupa varios megabytes de RAM (Apache vinculado con el intérprete y el código de la aplicación). Esto, junto con el bloqueo de cada instancia de Apache keepalive'd, es ineficiente.
Una solución común es usar 2 servidores Apache (ambos en el mismo servidor físico o en 2 servidores, según sea necesario) con diferentes configuraciones:
Luego puede expandir esta separación de contenido dinámico y estático cuando sea necesario , por ejemplo:
Otro enfoque con respecto a evitar el bloqueo de Apache es usar un equilibrador de carga con un manejo de conexión más inteligente, como Perlbal .
.. y mucho más. :-)
Keepalives puede ser bueno en algunos casos, puede ser muy malo en otros. Reducen el tiempo y el esfuerzo de configurar una nueva conexión, pero vinculan los recursos del servidor durante el tiempo de espera del keepalive. Ejemplos:
Como puede ver, KeepAliveTimeout también desempeñará un papel importante en la optimización del rendimiento de su servidor.
Mira tu patrón de uso y decide por ti mismo.
Definitivamente deberías usar KeepAlive On.
Ver:
http://httpd.apache.org/docs/2.0/mod/core.html#keepalive
De esa forma, el navegador reutilizará una única conexión TCP para enviar múltiples consultas. Por lo general, un sitio web tiene muchos componentes (página HTML, código javascript, imágenes). Mientras estos recursos estén en el mismo dominio, por lo tanto, pueden ser atendidos por el mismo servidor, una conexión KeepAlive da un gran impulso en el rendimiento ya que el navegador no tendrá que establecer una nueva conexión TCP.
Un navegador generalmente se abre alrededor de 3 conexiones paralelas a un dominio. Digamos que tienes 18 objetos en tu sitio. El navegador abriría 3 conexiones y descargaría 6 objetos en cada conexión, utilizando el modo KeepAlive. Sin KeepAlive, tendría que abrir 18 conexiones TCP, lo cual es muy lento.
La mayoría, o todos los navegadores modernos son compatibles con HTTP / 1.1, por lo que esto debería funcionar.
Ciertos servidores proxy HTTP como Squid no son compatibles con HTTP / 1.1, pero solicitan el uso de una conexión KeepAlive de todos modos.