Este documento describe varios parámetros importantes para optimizar el rendimiento de un servidor IIS, incluyendo la configuración de grupos de aplicaciones, reciclaje de procesos, límites de conexiones, y monitoreo de recursos del sistema como CPU, memoria, disco y red. Analizar estos parámetros bajo cargas controladas puede revelar cuellos de botella que pueden corregirse modificando la configuración de IIS o agregando más recursos hardware.

1. 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.
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.
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

2. 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.
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.
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.

3. 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:debuggerscdb.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:Debuggershuerfano.cmd
OrphanActionParams= %%1%%

4. 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.
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.
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
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.

5. 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.
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.
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 ).

6. 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.
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.
Cuando se monitorice el sistema, siempre deben incluirse contadores de las 4
áreas principales:
Memoria
Procesador
Disco
Red
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.

7. % 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.
% 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.
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.
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.

8. Páginas Active Server:
Tiempo de espera de petición (Request Wait Time): tiempo en
milisegundos de espera de 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.