SOSTIC

1. Introducción

La optimización de la configuración de nuestro servidor puede ser un factor decisivo en la consecución de un buen rendimiento del sistema.

Teniendo en cuenta que muchos usuarios no están dispuestos a esperar más que unos segundos a que se les muestre una página web, o que un error HTTP puede minar la confianza en un sitio web dedicado al comercio electrónico, un buen tiempo de respuesta y un alto grado de fiabilidad son factores tan importantes como el propio desarrollo de los contenidos de un servidor.

La monitorización de distintos parámetros del sistema y el estudio de la respuesta del servidor ante situaciones de estrés nos permitirán analizar la configuración vigente y los aspectos en los que pueda mejorarse.

2.1 Modo de aislamiento

• El modo de aislamiento en el que se ejecuta IIS es clave, tanto desde el punto de vista de la programación de páginas dinámicas, como de la configuración del servidor.
• Modo aislado de IIS 5: el modo de aislamiento alto (high) de aplicaciones incurre en una considerable penalización en el rendimiento debido a los costosos mecanismos RPC para la comunicación entre procesos.
• Modo de aislamiento de procesos de trabajo: A la mejora arquitectural que suponen los grupos de aplicaciones y los procesos de trabajo se unen sus características de reciclaje, tiempo de espera de inactividad, limitación de uso de CPU, web gardens, monitorización de estado, protección contra errores rápidos, o tiempos límite de inicio y finalización, que nos brindan multitud de parámetros y opciones con los que ajustar al máximo el rendimiento y la fiabilidad de nuestro servidor.
• En cualquiera de los dos casos, podemos beneficiarnos de características como limitación del número de conexiones y del ancho de banda, tiempos de espera, compresión HTTP o conexiones HTTP abiertas.

2.2 Reciclaje de los procesos de trabajo

• En la configuración de los grupos de aplicaciones se especifican las normas de reciclaje de los procesos de trabajo según criterios de:
• Tiempo transcurrido
• Solicitudes atendidas
• Hora del día
• Memoria utilizada
• El reciclaje puede ocurrir además con o sin solapamiento: por defecto, IIS generará los procesos de trabajo de reemplazo antes de que desaparezcan los existentes para que no se produzca pérdida interna de servicio; pero puede no ser así, por ejemplo debido a ausencia de recursos de memoria o CPU, o a que un proceso de trabajo se ha quedado bloqueado.
• Si programamos el reciclaje a una hora concreta (por ejemplo durante una ventana de mantenimiento), debemos tener en cuenta el consumo de recursos que supone. En el caso de un web garden con múltiples procesos de trabajo, puede ser mejor opción seguir un criterio de número de solicitudes atendidas.
• Si tenemos aplicaciones con fallos que producen bloqueos con el tiempo, se pueden establecer puntos temporales de reciclaje a lo largo del día.
• En el caso de aplicaciones con pérdidas de memoria, el mejor criterio puede ser el de memoria empleada por el proceso de trabajo.

No existiendo un criterio único universal, la configuración óptima dependerá de nuestra situación y de las aplicaciones que estamos gestionando.

2.4 Tiempo de espera de inactividad

• Ajustar el tiempo de espera de inactividad puede ayudar a liberar recursos que no están siendo utilizados, por ejemplo si hemos optado por una distribución de aplicaciones en muchos grupos de aplicaciones, cada grupo tiene asignado al menos 1 proceso de trabajo.
• Podemos rebajar el tiempo predeterminado de 20 minutos, por ejemplo en grupos de aplicaciones con peticiones poco frecuentes.
• En cualquier caso, debemos procurar que este parámetro no sea inferior al tiempo de espera de inactividad de las propias aplicaciones (ASP, PHP o ASP.net), ya que de lo contrario pueden producirse pérdidas de datos y servicios.

2.5 Límite de la cola de peticiones

• La cola de peticiones (que nutre HTTP.sys) de un grupo de aplicaciones, tiene una capacidad predeterminada de 1000 peticiones.
• Si la cola está llena, el servidor contestará a las peticiones entrantes con un mensaje de HTTP 503—Servicio no disponible.
• En una cola con excesiva capacidad, se acumularán las peticiones, dando a los usuarios sensación de lentitud en el servicio. Si no podemos permitirnos asignar más procesos de trabajo al grupo de aplicaciones, puede ser preferible un mensaje de Servicio no disponible para que el usuario intente acceder posteriormente.

2.6 Monitor de estado

• El Web Administration Service puede controlar la “salud” de los procesos de trabajo haciéndoles un ping a intervalos regulares de tiempo.
• Si el proceso de trabajo no contesta, IIS puede realizar dos acciones:
• Reciclar el proceso, terminándolo y sustituyéndolo por otro.
• Aislarlo, manteniéndolo en memoria, pero sin atender peticiones (crea un proceso huérfano), y generar otro proceso de trabajo para sustituirlo. Para esto, es necesario configurar algunos parámetros de la Metabase:
• OrphanWorkerProcess: debe tomar el valor TRUE (es false de forma predeterminada).
• OrphanActionExe: indica el ejecutable que se lanzará cuando se cree un proceso huérfano.
• OrphanActionParams: permite pasar parámetros al ejecutable indicado por OrphanActionExe.

Estos parámetros se pueden configurar tanto a nivel de todos los grupos de aplicaciones (/LM/W3SVC/AppPools) como dentro de cada grupo de aplicaciones particular (/LM/W3SVC/AppPools/nombre_del_grupo_de_aplicaciones).

• Hay que tener en cuenta que los procesos huérfanos pueden acumularse y consumir recursos de memoria, luego no conviene habilitar esta opción a menos que realmente se vaya a hacer un seguimiento de estos procesos y a liberar los recursos que emplean una vez se hayan analizado.
• Una manera de conseguir esto es utilizando las Debugging Tools, disponibles en el sitio web de Microsoft. Instalando estas herramientas en nuestro sistema, dispondremos de un mecanismo para volcar al disco duro la memoria de un proceso huérfano para su posterior estudio, y eliminar el proceso. Suponiendo que hemos instalado las Debugging Tools en C:\debuggers, crearíamos en ese directorio el archivo huerfano.cmd, con el siguiente contenido:

@if "%_echo%"=="" echo off
setlocal
set WORKINGDIR=c:\debuggers
set FILENAME=%WORKINGDIR%\crash.dmp
set LOG=%WORKINGDIR%\log.txt
set COMMAND=c:\debuggers\cdb.exe -c ".dump /o /mhf /u %FILENAME%;q" -p %1
echo %COMMAND% > %LOG%
%COMMAND%
            
Endlocal

• Después, asignamos los siguientes valores a los parámetros de la Metabase:
• OrphanWorkerProcess=“TRUE”
• OrphanActionExe=“C:\Debuggers\huerfano.cmd”
• OrphanActionParams=“%%1%%”
• De esta manera, cada vez que –en los grupos de aplicaciones configurados- surja un proceso de trabajo huérfano, volcaremos a disco la memoria del proceso y lo terminaremos.

2.9 Características de Calidad de Servicio (QoS)

• Mantenimiento de conexiones HTTP abiertas.
• Compresión HTTP.
• Límite de conexiones simultáneas.
• Tiempo de espera de la conexión.
• Límite de ancho de banda.

2.10 Parámetros del Registro de Windows

• En diversas ramas del Registro de Windows se pueden configurar múltiples valores de parámetros que afectan al rendimiento de IIS 6 relacionados con varios aspectos como gestión de cachés, registros y conexiones.

Nota: ver archivo complementario IIS 6 - Global Registry entries.pdf

2.11 Otros parámetros del servidor

• Memoria RAM: por lo general, la ampliación más rentable en cuanto a componentes físicos del servidor, es la memoria RAM.
• Maximizar el rendimiento para aplicaciones de red: por defecto, Windows 2003 se instala favoreciendo el rendimiento para compartir archivos. Podemos cambiar este parámetro en Propiedades de la Conexión de red > Propiedades de Compartir impresoras y archivos para redes Microsoft.
• Desfragmentación de discos: es conveniente desfragmentar periódicamente los discos duros del servidor para optimizar el rendimiento del subsistema de archivos.
• Archivo de paginación: establecer desde el principio un tamaño fijo suficiente para el archivo de paginación, de manera que se cree contiguo y no se fragmente con cada ampliación automática.
• Evitar aplicaciones CGI: utilizar extensiones ISAPI de servidor para no incurrir en la penalización de ejecución intrínseca al esquema de las aplicaciones CGI.
• Evitar el uso de FTP aislado: en el caso de tener muchos (cientos) de usuarios, gestionar todos los directorios asociados a las cuentas supone una carga considerable para el servidor. Si esta configuración es necesaria, dedicar si es posible un servidor en exclusiva a esta tarea.
• No abusar de los registros: el registro de actividad de un servidor con cientos o miles de sitios web puede ocupar un espacio en disco y generar un volumen de actividad considerables. Si es preciso, habilitar el formato binario de los archivos de registro asignando al parámetro CentralBinaryLoggingEnabled de la Metabase el valor True.

Los archivos de registro se generarán entonces en binario con la extensión *.ibl (Internet Binary Log) y en un solo archivo se registrará toda la actividad del servidor. Esto también puede ser útil en el caso de un servidor que hospede multitud de sitios web a la hora de generar informes estadísticos de actividad, ya que se concentra toda la información en un punto en lugar de en cientos o miles de archivos.

• Evitar el registro remoto: aunque la posibilidad de que los archivos de registro se almacenen en una unidad de red ofrece la ventaja de un repositorio de registro unificado, si la conexión del servidor con el punto remoto de almacenamiento no es buena puede resentirse el rendimiento. Además, la información viaja a priori sin encriptar, lo cual puede ser no deseable, y aunque pueda encriptarse el tráfico con IPSec, la encriptación siempre es una tarea que demanda CPU.
• Deshabilitar la indexación: en aquellos sitios web en los que no se empleen páginas de búsqueda en el contenido, es conveniente deshabilitar la indexación para liberar la CPU de una tarea no productiva.

3.1 Herramientas de monitorización

• La herramienta que proporciona Windows 2003 para monitorizar el sistema se ejecuta desde Inicio > Herramientas administrativas > Rendimiento.
• Está formado por:
• Monitor de sistema: muestra gráficamente información de múltiples parámetros del sistema.
• Registros y alertas de rendimiento: permite registrar la información monitorizada en archivos para su posterior análisis y la definición de mecanismos ante situaciones de alerta según los valores alcanzados por determinados parámetros.
• Otras herramientas que podemos emplear son:
• Administrador de tareas: nos permite ver las aplicaciones en ejecución, los procesos cargados en memoria y los recursos que consumen y diversos datos de rendimiento y nivel de saturación del sistema.
• Monitor de red: mayormente empleado para monitorizar conexiones y servicios de red y para generar estadísticas de uso de la red.
• Microsoft Web Application Stress Tool (WAST): una herramienta para someter a un servidor a pruebas de rendimiento simulando peticiones de clientes en un entorno controlado.

3.2 Monitorizar el rendimiento

• Analizar el servidor ante cargas de trabajo controladas nos permitirá descubrir los cuellos de botella en nuestro esquema, que son limitaciones en la configuración que afectan al rendimiento.
• Estas limitaciones pueden darse tanto en la parte hardware (CPU, memoria, conexión de red, velocidad del subsistema de almacenamiento) como en el software (aplicaciones, bases de datos…).
• Las acciones que se deban emprender pueden actuar directamente sobre la parte cuello de botella (añadir más CPUs o memoria RAM, revisar el código de las aplicaciones o emplear sistemas gestores de bases de datos más rápidos), o bien ajustando la configuración de IIS.

3.4 Proceso de optimización

• Es importante modificar un parámetro cada vez y analizar las consecuencias de dicha modificación.
• Muchas veces, deshacer un cuello de botella nos revela otro: traslada el problema a otra parte, aunque se trata de ir mejorando el rendimiento en cada paso.
• Una vez monitorizado y optimizado el servidor en un entorno controlado, se debe seguir el proceso en el entorno de producción: esto nos permitirá tener en perspectiva las posibles exigencias de nuestro servidor de cara a mantener el rendimiento conforme vayan aumentando las peticiones.

4.1 Contadores

• Cuando se monitorice el sistema, siempre deben incluirse contadores de las 4 áreas principales:
• Memoria
• Procesador
• Disco
• Red

4.2 Memoria

• MBytes disponibles (available Mbytes): debe estar por encima de 20.
• Bytes de caché (Cache bytes): si empieza a disminuir, IIS puede estar quedándose sin memoria.
• Bytes comprometidos (committed bytes): son los bytes asignados en la memoria virtual. Se deben mantener por debajo del 75% de la memoria virtual.
• Páginas/s (Pages/sec): errores de página que provocan lecturas o escrituras de página en disco. Es un indicador primario del tipo de errores que causan retraso en todo el sistema. Debe mantenerse por debajo de 20. Si toma un valor elevado (>= 80) debe añadirse más memoria RAM.
• Bytes de bloque no paginado (Pool nonpaged bytes): tamaño del área la memoria del sistema (memoria física usada por el sistema operativo) para objetos que no se pueden escribir en el disco, pero deben permanecer en la memoria física tanto tiempo como estén asignados. Un aumento paulatino a lo largo del tiempo puede indicar una “fuga” de memoria debida a programación defectuosa.

4.3 Procesador

• % de tiempo de procesador (% Processor Time): si se mantiene habitualmente elevado –por encima del 80%-, pero los indicadores de red y de disco son bajos, puede indicar un cuello de botella en el procesador.

4.4 Disco

• % Tiempo de disco (% Disk time): mantener tan bajo como sea posible. Un valor elevado indica que se debe optimizar la utilización del disco (particionamiento adecuado, desfragmentación…) o adquirir unidades de disco más rápidas.
• Media de bytes/transferencia (Avg. Disk Bytes/Transfer): debe mantenerse lo más alto posible.
• Long. media de la cola de disco (Avg. Disk Queue Length): debería ser <= 4.

4.5 Interfaz de red

• Total de bytes/s (Bytes Total/sec): comparar con el ancho de banda de la conexión de la tarjeta de red para averiguar si se está produciendo un cuello de botella en este subsistema.

4.6 Otros contadores

• Sistema:
• Longitud de la cola del procesador (Processor Queue Length): si de forma permanente muestra un valor >= 2, puede ser síntoma de un cuello de botella en el procesador.
• Archivo de paginación:
• % Uso (% Usage): el tamaño del archivo de paginación debe ser suficiente (de 1,5 a 2 veces el tamaño total de la memoria RAM del sistema). Si este porcentaje es elevado continuamente, el sistema necesita más memoria RAM.
• Servicio Web:
• Total de bytes/s. (Bytes Total/Sec): debería ser lo más alto posible.
• Memoria caché del servicio Web:
• Porcentaje de aciertos en la memoria caché de archivos (File Cache %): muestra la frecuencia con que IIS encuentra archivos en la caché. Si es un valor bajo, se puede considerar rediseñar las aplicaciones buscando mejorar este aspecto.
• Aciertos de la memoria caché de archivos (File Cache Hits): debe ser lo más alto posible si se tiene mucho contenido estático, pero puede ser bajo si el valor de Núcleo: aciertos de caché de URI % (Kernel: URI Cache Hits %) es elevado.
• Páginas Active Server:
• Tiempo de espera de petición (Request Wait Time): tiempo en milisegundos de esperade la petición más reciente en la cola. Debe ser bajo.
• Nº de peticiones en la cola (Requests Queued): debe mantenerse bajo. Tener en cuenta el límite de la cola del grupo de aplicaciones correspondiente.

Nº de peticiones/s (Requests/Sec): si se aprecia un descenso de este parámetro en situaciones de alta demanda, puede haber un cuello de botella en la aplicación.

Fichero pdf para descargar aquí.