Ajuste de IIS 10.0

Internet Information Services (IIS) 10.0 se incluye con Windows Server 2022. Utiliza un modelo de proceso similar al de IIS 8.5 e IIS 7.0. Un controlador web en modo kernel (http.sys) recibe y enruta solicitudes HTTP, y satisface las solicitudes de su caché de respuestas. Los procesos de trabajo se registran para los subespacios de URL y http.sys enruta la solicitud al proceso adecuado (o al conjunto de procesos para los grupos de aplicaciones).

HTTP.sys es responsable de la gestión de conexiones y la gestión de solicitudes. La solicitud se puede servir desde la caché de HTTP.sys o pasar a un proceso de trabajo para su posterior manipulación. Se pueden configurar varios procesos de trabajo, lo que proporciona aislamiento a un costo reducido. Para obtener más información sobre cómo funciona el control de solicitudes, consulta la siguiente ilustración:

HTTP.sys incluye una caché de respuestas. Cuando una solicitud coincide con una entrada en la caché de respuestas, HTTP.sys envía la respuesta de la caché directamente desde el modo kernel. Algunas plataformas de aplicaciones web, como ASP.NET, proporcionan mecanismos para permitir que cualquier contenido dinámico se almacene en caché en modo kernel. El controlador de archivos estáticos de IIS 10.0 almacena automáticamente en caché los archivos solicitados con frecuencia en http.sys.

Dado que un servidor web tiene componentes en modo kernel y en modo de usuario, ambos componentes deben ajustarse para obtener un rendimiento óptimo. Por lo tanto, el ajuste de IIS 10.0 para una carga de trabajo específica incluye la configuración de lo siguiente:

• HTTP.sys y la caché en modo kernel asociada

• Procesos de trabajo e IIS en modo de usuario, incluida la configuración del grupo de aplicaciones

• Ciertos parámetros de ajuste que afectan al rendimiento

En las secciones siguientes se describe cómo configurar los aspectos de modo kernel y modo de usuario de IIS 10.0.

Configuración del modo kernel

La configuración de HTTP.sys relacionada con el rendimiento se divide en dos grandes categorías: administración de caché y administración de conexiones y solicitudes. Toda la configuración del Registro se almacena en la siguiente entrada del Registro:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters

Nota Si el servicio HTTP ya se está ejecutando, debe reiniciarlo para que los cambios surtan efecto.

Configuración de administración de caché

Una ventaja que proporciona HTTP.sys es una caché en modo kernel. Si la respuesta está en la caché en modo kernel, puede satisfacer una solicitud HTTP completamente desde el modo kernel, lo que reduce significativamente el costo de CPU para manejar la solicitud. Sin embargo, la caché en modo kernel de IIS 10.0 se basa en la memoria física y el costo de una entrada es la memoria que ocupa.

Una entrada en la caché solo es útil cuando se utiliza. Sin embargo, la entrada siempre consume memoria física, independientemente de si se utiliza o no la entrada. Debe evaluar la utilidad de un elemento en la memoria caché (el ahorro de poder servirlo desde la memoria caché) y su costo (la memoria física ocupada) a lo largo de la vida útil de la entrada teniendo en cuenta los recursos disponibles (CPU y memoria física) y los requisitos de carga de trabajo. HTTP.sys intenta mantener solo los elementos útiles a los que se accede activamente en la memoria caché, pero puede aumentar el rendimiento del servidor web ajustando la memoria caché HTTP.sys para cargas de trabajo concretas.

A continuación se muestran algunas configuraciones útiles para la caché en modo kernel de HTTP.sys:

• UriEnableCache Valor predeterminado: 1

  Un valor distinto de cero habilita la respuesta en modo kernel y el almacenamiento en caché de fragmentos. Para la mayoría de las cargas de trabajo, la caché debe permanecer habilitada. Considere la posibilidad de deshabilitar la caché si espera una respuesta muy baja y el almacenamiento en caché de fragmentos.

• UriMaxCacheMegabyteCount Valor predeterminado: 0

  Valor distinto de cero que especifica la memoria máxima disponible para la memoria caché en modo kernel. El valor predeterminado, 0, permite que el sistema ajuste automáticamente la cantidad de memoria disponible para la memoria caché.

  Nota Al especificar el tamaño, solo se establece el máximo, y es posible que el sistema no permita que la memoria caché crezca hasta el tamaño máximo establecido.

  Â

• UriMaxUriBytes Valor predeterminado: 262144 bytes (256 KB)

  Tamaño máximo de una entrada en la caché en modo kernel. Las respuestas o fragmentos mayores que esto no se almacenan en caché. Si tiene suficiente memoria, considere aumentar el límite. Si la memoria es limitada y las entradas grandes están desplazando a las más pequeñas, podría ser útil reducir el límite.

• UriScavengerPeriod Valor predeterminado: 120 segundos

  Un eliminador examina periódicamente la caché de HTTP.sys y se eliminan las entradas a las que no se accede entre las exploraciones del eliminador. Si se establece el período de eliminación en un valor alto, se reduce el número de exploraciones de eliminación. Sin embargo, el uso de la memoria caché puede aumentar porque las entradas más antiguas a las que se accede con menos frecuencia pueden permanecer en la caché. Si se establece un período demasiado bajo, se realizarán exámenes de eliminación más frecuentes y se pueden producir demasiados vaciados y abandono de caché.

Configuración de administración de solicitudes y conexiones

En Windows Server 2022, HTTP.sys administra las conexiones automáticamente. Ya no se utilizan las siguientes opciones de configuración del Registro:

• MaxConnections

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\MaxConnections
  

• IdleConnectionsHighMark

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsHighMark
  

• IdleConnectionsLowMark

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsLowMark
  

• IdleListTrimmerPeriod

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleListTrimmerPeriod
  

• RequestBufferLookasideDepth

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\RequestBufferLookasideDepth
  

• InternalRequestLookasideDepth

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\InternalRequestLookasideDepth
  

Configuración del modo de usuario

La configuración de esta sección afecta al comportamiento del proceso de trabajo de IIS 10.0. La mayoría de estas opciones se pueden encontrar en el siguiente archivo de configuración XML:

%SystemRoot%\system32\inetsrv\config\applicationHost.config

Use Appcmd.exe, la consola de administración de IIS 10.0, los cmdlets de PowerShell WebAdministration o IISAdministration para cambiarlos. La mayoría de las opciones de configuración se detectan automáticamente y no requieren un reinicio de los procesos de trabajo de IIS 10.0 o del servidor de aplicaciones web. Para obtener más información sobre el archivo applicationHost.config, consulta Introducción a ApplicationHost.config.

Configuración de CPU ideal para hardware NUMA

A partir de Windows Server 2016, IIS 10.0 admite la asignación automática de CPU ideal para sus subprocesos de grupo de subprocesos con el fin de mejorar el rendimiento y la escalabilidad en el hardware NUMA. Esta característica está habilitada de forma predeterminada y se puede configurar a través de la siguiente clave del Registro:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\InetInfo\Parameters\ThreadPoolUseIdealCpu

Con esta característica habilitada, el administrador de subprocesos de IIS hace todo lo posible para distribuir uniformemente los subprocesos del grupo de subprocesos de IIS en todas las CPU de todos los nodos NUMA en función de sus cargas actuales. En general, se recomienda mantener esta configuración predeterminada sin cambios para el hardware NUMA.

Nota La configuración de CPU ideal es diferente de la configuración de asignación de nodos NUMA del proceso de trabajo (numaNodeAssignment y numaNodeAffinityMode) introducida en Configuración de CPU para un grupo de aplicaciones. La configuración de CPU ideal afecta a la forma en que IIS distribuye sus subprocesos del grupo de subprocesos, mientras que la configuración de asignación de nodos NUMA del proceso de trabajo determina en qué nodo NUMA se inicia un proceso de trabajo.

Configuración del comportamiento de la caché en modo de usuario

En esta sección se describe la configuración que afecta al comportamiento del almacenamiento en caché en IIS 10.0. La caché en modo de usuario se implementa como un módulo que escucha los eventos de almacenamiento en caché global generados por la canalización integrada. Para deshabilitar completamente la caché en modo de usuario, quite el módulo FileCacheModule (cachfile.dll) de la lista de módulos instalados en la sección de configuración system.webServer/globalModules en applicationHost.config.

system.webServer/almacenamiento en caché

Atributo	Descripción	Predeterminado
Activado	Deshabilita la caché de IIS en modo de usuario cuando se establece en False. Cuando la tasa de aciertos de caché es muy pequeña, puede deshabilitarla por completo para evitar la sobrecarga asociada a la ruta de acceso del código de caché. Al deshabilitar la caché en modo de usuario, no se deshabilita la caché en modo kernel.	Cierto
enableKernelCache	Deshabilita la caché en modo kernel cuando se establece en False.	Cierto
maxCacheSize	Limita el tamaño de la caché en modo de usuario de IIS al tamaño especificado en megabytes. IIS ajusta el valor predeterminado en función de la memoria disponible. Elija el valor cuidadosamente en función del tamaño del conjunto de archivos a los que se accede con frecuencia en función de la cantidad de RAM o el espacio de direcciones de proceso de IIS.	0
maxResponseSize	Almacena en caché los archivos hasta el tamaño especificado. El valor real depende del número y el tamaño de los archivos más grandes del conjunto de datos en comparación con la RAM disponible. El almacenamiento en caché de archivos grandes y solicitados con frecuencia puede reducir el uso de la CPU, el acceso al disco y las latencias asociadas.	262144

Ajustes de comportamiento de compresión

IIS, a partir de la versión 7.0, comprime el contenido estático de forma predeterminada. Además, la compresión de contenido dinámico está habilitada de forma predeterminada cuando se instala DynamicCompressionModule. La compresión reduce el uso del ancho de banda, pero aumenta el uso de la CPU. El contenido comprimido se almacena en caché en modo kernel si es posible. A partir de la versión 8.5, IIS permite controlar la compresión de forma independiente para contenido estático y dinámico. El contenido estático suele hacer referencia al contenido que no cambia, como los archivos GIF o HTM. Normalmente, el contenido dinámico se genera mediante scripts o código en el servidor, es decir, ASP.NET páginas. Puede personalizar la clasificación de cualquier extensión en particular como estática o dinámica.

Para deshabilitar completamente la compresión, quite StaticCompressionModule y DynamicCompressionModule de la lista de módulos de la sección system.webServer/globalModules de applicationHost.config.

sistema.webServer/httpCompresión

Atributo	Descripción	Predeterminado
staticCompression-EnableCpuUsage staticCompression-DisableCpuUsage dynamicCompression-EnableCpuUsage dynamicCompression-DisableCpuUsage	Habilita o deshabilita la compresión si el porcentaje actual de uso de CPU supera o baja los límites especificados. A partir de IIS 7.0, la compresión se deshabilita automáticamente si la CPU de estado estable aumenta por encima del umbral de deshabilitación. La compresión está habilitada si la CPU cae por debajo del umbral de habilitación.	50, 100, 50 y 90 respectivamente
directorio	Especifica el directorio en el que se almacenan temporalmente y se almacenan en caché las versiones comprimidas de los archivos estáticos. Considere la posibilidad de mover este directorio fuera de la unidad del sistema si se accede a él con frecuencia.	%SystemDrive%\inetpub\temp\IIS Archivos comprimidos temporales
doDiskSpaceLimiting	Especifica si existe un límite para la cantidad de espacio en disco que pueden ocupar todos los archivos comprimidos. Los archivos comprimidos se almacenan en el directorio de compresión especificado por el atributo directory .	Cierto
maxDiskSpaceUsage	Especifica el número de bytes de espacio en disco que pueden ocupar los archivos comprimidos en el directorio de compresión. Es posible que sea necesario aumentar esta configuración si el tamaño total de todo el contenido comprimido es demasiado grande.	100 MB

system.webServer/urlCompression

Atributo	Descripción	Predeterminado
doStaticCompression	Especifica si se comprime el contenido estático.	Cierto
doDynamicCompression	Especifica si el contenido dinámico se comprime.	Cierto

Nota:

En el caso de los servidores que ejecutan IIS 10.0 que tienen un uso medio de CPU bajo, considere la posibilidad de habilitar la compresión para el contenido dinámico, especialmente si las respuestas son grandes. Esto debe hacerse primero en un entorno de prueba para evaluar el efecto en el uso de la CPU desde la línea de base.

Ajuste de la lista de documentos predeterminada

El módulo de documento predeterminado maneja las solicitudes HTTP para la raíz de un directorio y las traduce en solicitudes para un archivo específico, como Default.htm o Index.htm. En promedio, alrededor del 25 por ciento de todas las solicitudes en Internet pasan por la ruta de documentos predeterminada. Esto varía significativamente para cada sitio. Cuando una solicitud HTTP no especifica un nombre de archivo, el módulo de documentos predeterminados busca en la lista de documentos predeterminados permitidos para cada nombre en el sistema de archivos. Esto puede afectar negativamente al rendimiento, especialmente si para acceder al contenido es necesario hacer un viaje de ida y vuelta a la red o tocar un disco.

Puede evitar la sobrecarga desactivando selectivamente los documentos predeterminados y reduciendo u ordenando la lista de documentos. En el caso de los sitios web que utilizan un documento predeterminado, debe reducir la lista a solo los tipos de documentos predeterminados que se utilizan. Además, ordene la lista de modo que comience con el nombre de archivo de documento predeterminado al que se accede con más frecuencia.

Puede establecer de forma selectiva el comportamiento predeterminado del documento en direcciones URL concretas personalizando la configuración dentro de una etiqueta de ubicación en applicationHost.config o insertando un archivo web.config directamente en el directorio de contenido. Esto permite un enfoque híbrido, que habilita los documentos predeterminados solo donde son necesarios y establece la lista con el nombre de archivo correcto para cada URL.

Para deshabilitar completamente los documentos predeterminados, quite DefaultDocumentModule de la lista de módulos de la sección system.webServer/globalModules de applicationHost.config.

sistema.webServer/defaultDocument

Atributo	Descripción	Predeterminado
Habilitado	Especifica que los documentos predeterminados están habilitados.	Cierto
Elemento <files>	Especifica los nombres de archivo que se configuran como documentos predeterminados.	La lista predeterminada es Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htmy Default.aspx.

Registro binario central

Cuando la sesión del servidor tiene numerosos grupos de direcciones URL, el proceso de crear cientos de archivos de registro con formato para grupos de direcciones URL individuales y escribir los datos de registro en un disco puede consumir rápidamente recursos valiosos de CPU y memoria, lo que crea problemas de rendimiento y escalabilidad. El registro binario centralizado minimiza la cantidad de recursos del sistema que se usan para el registro, al mismo tiempo que proporciona datos de registro detallados para las organizaciones que lo requieren. El análisis de registros en formato binario requiere una herramienta de posprocesamiento.

Puede habilitar el registro binario central estableciendo el atributo centralLogFileMode en CentralBinary y estableciendo el atributo enabled en True. Considere la posibilidad de mover la ubicación del archivo de registro central fuera de la partición del sistema a una unidad de registro dedicada para evitar la contención entre las actividades del sistema y las actividades de registro.

sistema.applicationHost/registro

Atributo	Descripción	Predeterminado
centralLogFileMode	Especifica el modo de registro de un servidor. Cambie este valor a CentralBinary para habilitar el registro binario central.	Sitio

system.applicationHost/log/centralBinaryLogFile

Atributo	Descripción	Predeterminado
Habilitado	Especifica si el registro binario central está habilitado.	Falso
directorio	Especifica el directorio donde se escriben las entradas de registro.	%SystemDrive%\inetpub\logs\LogFiles

Ajustes de aplicaciones y sitios

La siguiente configuración se relaciona con el grupo de aplicaciones y los ajustes del sitio.

system.applicationHost/applicationPools/applicationPoolDefaults

Atributo	Descripción	Predeterminado
queueLength	Indica para HTTP.sys cuántas solicitudes se ponen en cola para un grupo de aplicaciones antes de que se rechacen las solicitudes futuras. Cuando se supera el valor de esta propiedad, IIS rechaza las solicitudes posteriores con un error 503. Considere la posibilidad de aumentar esto para las aplicaciones que se comunican con almacenes de datos back-end de alta latencia si se observan errores 503.	1 000
enable32BitAppOnWin64	Cuando es True, permite que una aplicación de 32 bits se ejecute en un equipo que tenga un procesador de 64 bits. Considere la posibilidad de habilitar el modo de 32 bits si el consumo de memoria es un problema. Dado que los tamaños de puntero e instrucción son más pequeños, las aplicaciones de 32 bits usan menos memoria que las aplicaciones de 64 bits. El inconveniente de ejecutar aplicaciones de 32 bits en un equipo de 64 bits es que el espacio de direcciones en modo de usuario está limitado a 4 GB.	Falso

system.applicationHost/sites/VirtualDirectoryDefault

Atributo	Descripción	Predeterminado
allowSubDirConfig	Especifica si IIS busca archivos web.config en directorios de contenido inferiores al nivel actual (True) o no busca archivos web.config en directorios de contenido inferiores al nivel actual (False). Al imponer una limitación simple, que permite la configuración solo en directorios virtuales, IISÂ 10.0 puede saber que, a menos que /<name>.htm sea un directorio virtual, no debe buscar un archivo de configuración. Omitir las operaciones de archivos adicionales puede mejorar significativamente el rendimiento de los sitios web que tienen un conjunto muy grande de contenido estático al que se accede aleatoriamente.	Cierto

Administración de módulos de IIS 10.0

IIS 10.0 se ha factorizado en varios módulos extensibles por el usuario para admitir una estructura modular. Esta factorización tiene un pequeño costo. Para cada módulo, la canalización integrada debe llamar al módulo para cada evento que sea relevante para el módulo. Esto sucede independientemente de si el módulo debe realizar algún trabajo. Puede conservar los ciclos de CPU y la memoria eliminando todos los módulos que no son relevantes para un sitio web en particular.

Un servidor web optimizado para archivos estáticos simples puede incluir solo los cinco módulos siguientes: UriCacheModule, HttpCacheModule, StaticFileModule, AnonymousAuthenticationModule y HttpLoggingModule.

Para eliminar módulos de applicationHost.config, elimine todas las referencias al módulo de las secciones system.webServer/handlers y system.webServer/modules, además de eliminar la declaración del módulo en system.webServer/globalModules.

Configuración clásica de ASP

El costo principal de procesar una solicitud ASP clásica incluye la inicialización de un motor de scripts, la compilación del script ASP solicitado en una plantilla ASP y la ejecución de la plantilla en el motor de scripts. Aunque el costo de ejecución de la plantilla depende de la complejidad del script ASP solicitado, el módulo ASP clásico de IIS puede almacenar en caché motores de script en memoria y plantillas de caché tanto en memoria como en disco (solo si se desborda la caché de plantillas en memoria) para aumentar el rendimiento en escenarios enlazados a la CPU.

Las siguientes opciones se utilizan para configurar la caché de plantillas ASP clásicas y la caché del motor de scripts, y no afectan a ASP.NET configuración.

sistema.webServer/asp/caché

Atributo	Descripción	Predeterminado
diskTemplateCacheDirectory	Nombre del directorio que ASP utiliza para almacenar plantillas compiladas cuando se desborda la caché en memoria. Recomendación: Establézcalo en un directorio que no se use mucho, por ejemplo, una unidad que no se comparta con el sistema operativo, el registro de IIS u otro contenido al que se acceda con frecuencia.	%SystemDrive%\inetpub\temp\ASP - Plantillas compiladas
maxDiskTemplateCacheFiles	Especifica el número máximo de plantillas ASP compiladas que se pueden almacenar en caché en el disco. Recomendación: Establézcalo en el valor máximo de 0x7FFFFFFF.	2000
scriptFileCacheSize	Este atributo especifica el número máximo de plantillas ASP compiladas que se pueden almacenar en caché en la memoria. Recomendación: Establézcalo en al menos el número de scripts ASP solicitados con frecuencia que sirve un grupo de aplicaciones. Si es posible, establézcalo en tantas plantillas ASP como permitan los límites de memoria.	500
scriptEngineCacheMax	Especifica el número máximo de motores de scripts que se mantendrán almacenados en caché en la memoria. Recomendación: Establézcalo en al menos el número de scripts ASP solicitados con frecuencia que sirve un grupo de aplicaciones. Si es posible, establézcalo en tantos motores de script como permita el límite de memoria.	250

sistema.webServer/asp/límites

Atributo	Descripción	Predeterminado
processorThreadMax	Especifica el número máximo de subprocesos de trabajo por procesador que ASP puede crear. Aumente si la configuración actual es insuficiente para manejar la carga, lo que puede causar errores al atender solicitudes o provocar un uso insuficiente de los recursos de la CPU.	25

sistema.webServer/asp/comPlus

Atributo	Descripción	Predeterminado
executeInMta	Establézcalo en True si se detectan errores o errores mientras IIS sirve contenido ASP. Esto puede ocurrir, por ejemplo, cuando se hospedan varios sitios aislados en los que cada sitio se ejecuta bajo su propio proceso de trabajo. Normalmente, los errores se notifican desde COM+ en el Visor de eventos. Esta configuración habilita el modelo de apartamento multiproceso en ASP.	Falso

Configuración de simultaneidad de ASP.NET

ASP.NET 3.5

De forma predeterminada, ASP.NET limita la simultaneidad de solicitudes para reducir el consumo de memoria de estado estable en el servidor. Es posible que las aplicaciones de alta simultaneidad necesiten ajustar algunas opciones de configuración para mejorar el rendimiento general. Puede cambiar esta configuración en aspnet.config archivo:

<system.web>
  <applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>

La siguiente configuración es útil para utilizar completamente los recursos de un sistema:

• maxConcurrentRequestPerCpu Valor predeterminado: 5000

  Esta configuración limita el número máximo de solicitudes de ASP.NET en ejecución simultánea en un sistema. El valor predeterminado es conservador para reducir el consumo de memoria de ASP.NET aplicaciones. Considere la posibilidad de aumentar este límite en los sistemas que ejecutan aplicaciones que realizan operaciones de E/S largas y sincrónicas. De lo contrario, los usuarios pueden experimentar una latencia alta debido a errores de cola o solicitudes debido a que se superan los límites de cola con una carga alta cuando se usa la configuración predeterminada.

ASP.NET 4.6

Además de la configuración maxConcurrentRequestPerCpu, ASP.NET 4.7 también proporciona configuraciones para mejorar el rendimiento en las aplicaciones que dependen en gran medida del funcionamiento asincrónico. La configuración se puede cambiar en aspnet.config archivo.

<system.web>
  <applicationPool percentCpuLimit="90" percentCpuLimitMinActiveRequestPerCpu="100"/>
</system.web>

• percentCpuLimit Valor predeterminado: 90 La solicitud asincrónica tiene algunos problemas de escalabilidad cuando se coloca una gran carga (más allá de las capacidades de hardware) en dicho escenario. El problema se debe a la naturaleza de la asignación en escenarios asincrónicos. En estas condiciones, la asignación se producirá cuando se inicie la operación asincrónica y se consumirá cuando se complete. En ese momento, es muy posible que los objetos hayan sido movidos a la generación 1 o 2 por GC. Cuando esto sucede, el aumento de la carga mostrará un aumento a petición por segundo (rps) hasta un punto. Una vez que pasemos ese punto, el tiempo dedicado a GC comenzará a convertirse en un problema y el rps comenzará a bajar, teniendo un efecto de escala negativo. Para solucionar el problema, cuando el uso de la CPU supera la configuración de percentCpuLimit, las solicitudes se enviarán a la cola nativa de ASP.NET.
• percentCpuLimitMinActiveRequestPerCpu Valor predeterminado: 100 La limitación de CPU (configuración de percentCpuLimit) no se basa en el número de solicitudes, sino en lo costosas que sean. Como resultado, podría haber solo unas pocas solicitudes intensivas de CPU que provoquen una copia de seguridad en la cola nativa sin forma de vaciarla aparte de las solicitudes entrantes. Para resolver este problema, percentCpuLimitMinActiveRequestPerCpu se puede usar para asegurarse de que se atiende un número mínimo de solicitudes antes de que se inicie la limitación.

Proceso de los trabajadores y opciones de reciclaje

Puede configurar opciones para reciclar procesos de trabajo de IIS y proporcionar soluciones prácticas a situaciones o eventos agudos sin necesidad de intervención o restablecimiento de un servicio o equipo. Estas situaciones y eventos incluyen pérdidas de memoria, aumento de la carga de memoria o procesos de trabajo que no responden o están inactivos. En condiciones normales, es posible que las opciones de reciclaje no sean necesarias y que el reciclaje se pueda desactivar o que el sistema se configure para reciclar con muy poca frecuencia.

Puede habilitar el reciclaje de procesos para una aplicación determinada agregando atributos al elemento recycling/periodicRestart . El evento de reciclaje se puede desencadenar mediante varios eventos, incluido el uso de memoria, un número fijo de solicitudes y un período de tiempo fijo. Cuando se recicla un proceso de trabajo, se purgan las solicitudes en cola y en ejecución, y se inicia simultáneamente un nuevo proceso para atender nuevas solicitudes. El elemento recycling/periodicRestart es por aplicación, lo que significa que cada atributo de la tabla siguiente se divide en particiones por aplicación.

system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart

Atributo	Descripción	Predeterminado
memoria	Habilite el reciclaje de procesos si el consumo de memoria virtual supera el límite especificado en kilobytes. Esta es una configuración útil para equipos de 32 bits que tienen un espacio de direcciones pequeño de 2 GB. Puede ayudar a evitar solicitudes fallidas debido a errores de memoria insuficiente.	0
privateMemory	Habilite el reciclaje de procesos si las asignaciones de memoria privada superan un límite especificado en kilobytes.	0
solicitudes	Habilite el reciclaje de procesos después de un cierto número de solicitudes.	0
Tiempo	Habilite el reciclaje de procesos después de un período de tiempo especificado.	29:00:00

Ajuste dinámico de páginas de salida de procesos de trabajo

A partir de Windows Server 2012 R2, IIS ofrece la opción de configurar el proceso de trabajo para que se suspenda después de que haya estado inactivo durante un tiempo (además de la opción de finalizar, que existía desde IIS 7).

El objetivo principal de las características de salida de página del proceso de trabajo inactivo y de finalización del proceso de trabajo inactivo es conservar la utilización de la memoria en el servidor, ya que un sitio puede consumir mucha memoria incluso si está allí sentado, escuchando. Dependiendo de la tecnología utilizada en el sitio (contenido estático frente a ASP.NET frente a otros marcos), la memoria utilizada puede oscilar entre unos 10 MB y cientos de MB, y esto significa que si su servidor está configurado con muchos sitios, averiguar la configuración más eficaz para sus sitios puede mejorar drásticamente el rendimiento de los sitios activos y suspendidos.

Antes de entrar en detalles, debemos tener en cuenta que si no hay restricciones de memoria, probablemente sea mejor simplemente configurar los sitios para que nunca se suspendan ni finalicen. Después de todo, tiene poco valor terminar un proceso de trabajo si es el único en la máquina.

Nota:

En caso de que el sitio ejecute código inestable, como código con una pérdida de memoria, o inestable, configurar el sitio para que termine en inactivo puede ser una alternativa rápida y sucia para corregir el error de código. Esto no es algo que recomendaríamos, pero en un momento de crisis, puede ser mejor usar esta característica como un mecanismo de limpieza mientras se trabaja en una solución más permanente.]

Otro factor a tener en cuenta es que si el sitio utiliza mucha memoria, el proceso de suspensión en sí mismo pasa factura, ya que el equipo tiene que escribir los datos utilizados por el proceso de trabajo en el disco. Si el proceso de trabajo utiliza una gran cantidad de memoria, suspenderlo puede ser más costoso que el costo de tener que esperar a que se inicie la copia de seguridad.

Para aprovechar al máximo la característica de suspensión del proceso de trabajo, debe revisar los sitios de cada grupo de aplicaciones y decidir cuáles deben suspenderse, cuáles deben finalizarse y cuáles deben estar activas indefinidamente. Para cada acción y cada sitio, debe determinar el período de tiempo de espera ideal.

Idealmente, los sitios que configurará para la suspensión o terminación son aquellos que tienen visitantes todos los días, pero no los suficientes como para garantizar que se mantengan activos todo el tiempo. Por lo general, se trata de sitios con alrededor de 20 visitantes únicos al día o menos. Puede analizar los patrones de tráfico utilizando los archivos de registro del sitio y calcular el tráfico diario promedio.

Tenga en cuenta que una vez que un usuario específico se conecta al sitio, normalmente permanecerá en él durante al menos un tiempo, realizando solicitudes adicionales, por lo que es posible que solo contar las solicitudes diarias no refleje con precisión los patrones de tráfico reales. Para obtener una lectura más precisa, también puede utilizar una herramienta, como Microsoft Excel, para calcular el tiempo promedio entre solicitudes. Por ejemplo:

Número	URL de la solicitud	Tiempo de solicitud	Delta
1	/FuenteSilverLight/Geosource.web/grosource.html	10:01
2	/FuenteSilverLight/Geosource.web/sliverlight.js	10:10	0:09
3	/FuenteSilverLight/Geosource.web/clientbin/geo/1.aspx	10:11	0:01
4	/lClientAccessPolicy.xml	10:12	0:01
5	/ FuenteSilverLight/GeosourcewebService/Servicio.asmx	10:23	0:11
6	/ FuenteSilverLight/Geosource.web/GeoSearchServer...¦.	11:50	1:27
7	/rest/Services/CachedServices/Silverlight_load_la...¦	1,250	1:00
8	/rest/Services/CachedServices/Silverlight_basemap...¦.	12:51	0:01
9	/rest/Services/DynamicService/ Silverlight_basemap...¦.	12:59	0:08
10	/rest/Services/CachedServices/Ortho_2004_cache.as...	13:40	0:41
11	/rest/Services/CachedServices/Ortho_2005_cache.js	13:40	0:00
12	/rest/Services/CachedServices/OrthoBaseEngine.aspx	13:41	0:01

La parte difícil, sin embargo, es averiguar qué configuración aplicar para que tenga sentido. En nuestro caso, el sitio recibe un montón de solicitudes de los usuarios, y la tabla anterior muestra que ocurrieron un total de 4 sesiones únicas en un período de 4 horas. Con la configuración predeterminada para la suspensión del proceso de trabajo del grupo de aplicaciones, el sitio finalizaría después del tiempo de espera predeterminado de 20 minutos, lo que significa que cada uno de estos usuarios experimentaría el ciclo de puesta en marcha del sitio. Esto lo convierte en un candidato ideal para la suspensión del proceso de trabajo, ya que durante la mayor parte del tiempo, el sitio está inactivo y, por lo tanto, suspenderlo conservaría los recursos y permitiría a los usuarios llegar al sitio casi al instante.

Una nota final y muy importante sobre esto es que el rendimiento del disco es crucial para esta función. Debido a que el proceso de suspensión y activación implica escribir y leer una gran cantidad de datos en el disco duro, recomendamos encarecidamente utilizar un disco rápido para esto. Las unidades de estado sólido (SSD) son ideales y muy recomendables para esto, y debe asegurarse de que el archivo de paginación de Windows esté almacenado en ellas (si el sistema operativo en sí no está instalado en el SSD, configure el sistema operativo para mover el archivo de paginación a él).

Tanto si utiliza un SSD como si no, también se recomienda fijar el tamaño del archivo de paginación para permitir la escritura de los datos de salida de página en él sin cambiar el tamaño del archivo. El cambio de tamaño del archivo de paginación puede producirse cuando el sistema operativo necesita almacenar datos en el archivo de paginación, ya que, de forma predeterminada, Windows está configurado para ajustar automáticamente su tamaño en función de la necesidad. Al establecer el tamaño en uno fijo, puede evitar el cambio de tamaño y mejorar mucho el rendimiento.

Para configurar un tamaño de archivo de paginación prefijado, debe calcular su tamaño ideal, que depende de la cantidad de sitios que vaya a suspender y de la cantidad de memoria que consuman. Si el promedio es de 200 MB para un proceso de trabajo activo y tiene 500 sitios en los servidores que se suspenderán, el archivo de paginación debe tener al menos (200 * 500) MB por encima del tamaño base del archivo de paginación (es decir, base + 100 GB en nuestro ejemplo).

Nota:

Cuando los sitios están suspendidos, consumirán aproximadamente 6 MB cada uno, por lo que en nuestro caso, el uso de memoria si todos los sitios están suspendidos sería de alrededor de 3 GB. Sin embargo, en realidad, es probable que nunca los suspendas todos al mismo tiempo.

Parámetros de ajuste de seguridad de la capa de transporte

El uso de la seguridad de la capa de transporte (TLS) impone un costo de CPU adicional. El componente más costoso de TLS es el costo de establecer un establecimiento de sesión, ya que implica un protocolo de enlace completo. La reconexión, el cifrado y el descifrado también aumentan el costo. Para mejorar el rendimiento de TLS, haga lo siguiente:

• Habilite las señales de mantenimiento HTTP para las sesiones TLS. Esto elimina los costos de establecimiento de la sesión.

• Reutilice las sesiones cuando corresponda, especialmente con tráfico que no sea de conexión permanente.

• Aplique selectivamente el cifrado solo a las páginas o partes del sitio que lo necesiten, en lugar de a todo el sitio.

Nota:

• Las claves más grandes proporcionan más seguridad, pero también utilizan más tiempo de CPU.
• Es posible que no sea necesario cifrar todos los componentes. Sin embargo, la combinación de HTTP y HTTPS simples puede dar lugar a una advertencia emergente que indica que no todo el contenido de la página es seguro.

Interfaz de programación de aplicaciones de servidor de Internet (ISAPI)

No se necesitan parámetros de ajuste especiales para las aplicaciones ISAPI. Si escribe una extensión ISAPI privada, asegúrese de que esté escrita para el rendimiento y el uso de recursos.

Directrices de ajuste de código administrado

El modelo de canalización integrado en IIS 10.0 permite un alto grado de flexibilidad y extensibilidad. Los módulos personalizados que se implementan en código nativo o administrado se pueden insertar en la canalización o pueden reemplazar los módulos existentes. Aunque este modelo de extensibilidad ofrece comodidad y simplicidad, debe tener cuidado antes de insertar nuevos módulos administrados que se enlazan a eventos globales. Agregar un módulo administrado global significa que todas las solicitudes, incluidas las solicitudes de archivos estáticos, deben tocar código administrado. Los módulos personalizados son susceptibles a eventos como la recolección de elementos no utilizados. Además, los módulos personalizados agregan un costo de CPU significativo debido al cálculo de referencias de datos entre el código nativo y el administrado. Si es posible, debe establecer preCondition en managedHandler para el módulo administrado.

Para obtener un mejor rendimiento de inicio en frío, asegúrese de precompilar el sitio web ASP.NET o aproveche la característica de inicialización de aplicaciones de IIS para preparar la aplicación.

Si el estado de sesión no es necesario, asegúrese de desactivarlo para cada página.

Si hay muchas operaciones enlazadas de E/S, intente usar una versión asincrónica de las API relevantes, lo que le proporcionará una escalabilidad mucho mejor.

Además, el uso correcto de la caché de salida también aumentará el rendimiento de su sitio web.

Cuando ejecute varios hosts que contengan ASP.NET scripts en modo aislado (un grupo de aplicaciones por sitio), supervise el uso de la memoria. Asegúrese de que el servidor tiene suficiente RAM para el número esperado de grupos de aplicaciones que se ejecutan simultáneamente. Considere la posibilidad de utilizar varios dominios de aplicación en lugar de varios procesos aislados.

Otros problemas que afectan al rendimiento de IIS

Los siguientes problemas pueden afectar al rendimiento de IIS:

• Instalación de filtros que no tienen en cuenta la caché

  La instalación de un filtro que no es compatible con la caché HTTP hace que IIS deshabilite completamente el almacenamiento en caché, lo que da como resultado un rendimiento deficiente. Los filtros ISAPI que se escribieron antes de IIS 6.0 pueden provocar este comportamiento.

• Solicitudes de interfaz de puerta de enlace común (CGI)

  Por motivos de rendimiento, no se recomienda el uso de aplicaciones CGI para atender solicitudes con IIS. Con frecuencia, la creación y eliminación de procesos CGI implica una sobrecarga significativa. Las mejores alternativas incluyen el uso de FastCGI, scripts de aplicaciones ISAPI y scripts ASP o ASP.NET. El aislamiento está disponible para cada una de estas opciones.

Referencias adicionales

• Ajuste del rendimiento del servidor web
• Ajuste HTTP 1.1/2