0

Tuning IHS: determinando el número máximo de conexiones simultáneas

La primera decisión que debemos tomar a la hora de tunear nuestro frontal web es determinar cuántas conexiones simultáneas va a tener que soportar nuestra instalación. Muchas decisiones que tendremos que tomar a posteriori dependerán de este valor.

La carga del servidor web está relacionada con la típica de un día laboral, pudiendo ser algo parecido a esto:

Gráfica accesos IHS

La gráfica es simplemente orientativa, pues la carga de cada instalación depende de muchos factores.

El número máximo de conexiones simultáneas debe establecerse teniendo en cuenta el momento de más carga de trabajo del día. Hay que tener en cuenta que el número de conexiones simultáneas está vagamente relacionado con el número de usuarios accediendo al sítio web. En cualquier momento del día, un simple usuario puede requerir de una a cuatro conexiones TCP independientes.

La forma más utilizada para determinar el número máximo de conexiones simultáneas es monitorizar los informes del mod_status durante el día, hasta comprender el funcionamiento habitual de nuestro sitio. Otra opción es utilizar mod_mpmstats.

Los ejemplos que siguen a continuación están pensados para una instalación de una instancia de IHS. En entornos clusterizados horizontalmente habría que tener en cuenta un número de conexiones adicionales para las tareas de mantenimiento, cuando alguno de los nodos esté offline.

Monitorizando con mod_status

1.- Añadimos estas directivas al httpd.conf (o cdescomentamos las existentes):

# Ejemplo para IBM HTTP Server 2.0 y superiores

Loadmodule status_module modules/mod_status.so
<Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from .example.com    <— cambiar por “.” + nuestro nombre d edominio
</Location>

2.- Solicitar la página de estado (http://www.example.com/server-status/) varias veces a lo largo del día, buscando las líneas como esta:

192 requests currently being processed, 287 idle workers

El número de peticiones procesándose actualmente es el número de conexiones simultáneas en ese momento. Monitorizar dicho valos a lo largo del día nos dará una idea del número de conexiones que tendremos que manejar.

Monitorizando con mod_mpmstats

1.- Hasta IHS 6.1: copiar la versión adecuada para nuestro SO del mod_mpmstats en el directorio modules. Podemos obtener el mod_mpmstats del ihsdiag package de IBM. para IHS 7.0 y posteriores el mod_mpmstats viene activado por defecto.

2.- Añadir las siguientes líneas al final del httpd.conf:

LoadModule mpmstats_module modules/mod_mpmstats.so
ReportInterval 90

3.- Buscar entradas como las siguientes en el error log para ver cuántas conexiones simultáneas manejamos a lo largo del día:

[Thu Aug 19 14:01:00 2004] [notice] mpmstats: rdy 712 bsy 312 rd 121 wr 173 ka 0 log 0 dns 0 cls 18
[Thu Aug 19 14:02:30 2004] [notice] mpmstats: rdy 809 bsy 215 rd 131 wr 44 ka 0 log 0 dns 0 cls 40
[Thu Aug 19 14:04:01 2004] [notice] mpmstats: rdy 707 bsy 317 rd 193 wr 97 ka 0 log 0 dns 0 cls 27
[Thu Aug 19 14:05:32 2004] [notice] mpmstats: rdy 731 bsy 293 rd 196 wr 39 ka 0 log 0 dns 0 cls 58

Si nuestro servidor no ha sido configurado para soportar suficientes conexiones simultáneas veremos los siguientes errores en nuestro error log y los clientes experimentarán importantes retrasos al acceder a nuestro sitio:

Windows
[warn] Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting

Linux y Unix
[error] server reached MaxClients setting, consider raising the MaxClients setting

Cuando se ha alcanzado el número máximo de clientes, las nuevas conexiones se almacenan en el buffer del Sistema Operativo y no consumen hilos (request processing threads) hasta que se completa el trabajo que se esté realizando en ese momento. El tamaño de este buffer es controlado por el propio SO y estará influenciado por la directiva  ListenBacklog.

Una vez que se ha determinado el número máximo de conexiones simultáneas es recomendable añadir un 25% adicional por seguridad.

Si el requerimiento de conexiones simultáneas supera las 3000-4000 deberemos plantearnos instalar más instancias IHS, preferiblemente en instancias de Sistemas Operativos diferentes. Sobrepasar este límite no está recomendado, pues pude provocar comportamientos impredecibles.

Nota: modificar el KeepAliveTimeout puede afectar aparentemente al número de peticiones simultáneas que está procesando el servidor.

Aumentar el valor de KeepAliveTimeout reduce el número de hilos disponibles para servir nuevas peticiones y resultará en un máximo de conexiones simultáneas más elevado, que tendrá que ser soportado por el servidor web.

Disminuir el KeepAliveTimeout puede implicar carga adicional en el servidor al tener que manejar configuraciones de conexiones TCP innecesárias. Un valor enre 5 y 10 segundos es razonable para servir peticiones en redes con alta velocidad y baja latencia.

Podemos determinar si el KeepAliveTimeout está configurado correctamente echando un vistazo a la salida del mod_mpmstats:

[Thu Aug 28 10:12:17 2008] [notice] mpmstats: rdy 0 bsy 600 rd 1 wr 70 ka 484 log 0 dns 0 cls 45

Aquí se ve que todos los hilos están ocupados (0 threads están ready “rdy”, 600 están busy “bsy”). 484 están esperando una petición keepalive (“ka”), mientras el servidor está rechazando peticiones porque no tiene hilos disponibles para trabajar.

Disminuyendo el valor de KeepAliveTimeout conseguiríamos hacer que los hilos en “ka” cerrasen antes sus conexiones y estuviesen disponibles para trabajar en menos tiempo.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *