Optimización de IIS 10.0
Internet Information Services (IIS) 10.0 se incluye con Windows Server 2022. Usa 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 las solicitudes HTTP, y satisface las solicitudes desde su memoria caché de respuesta. Se registran procesos de trabajo para los subespacios de direcciones URL y http.sys enruta la solicitud al proceso adecuado (o conjunto de procesos para los grupos de aplicaciones).
HTTP.sys es responsable de la administración de las conexiones y el control de las solicitudes. La solicitud se puede atender desde la memoria caché de HTTP.sys o se puede pasar a un proceso de trabajo para un control adicional. 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 ilustración siguiente:
HTTP.sys incluye una memoria caché de respuesta. Cuando una solicitud coincide con una entrada de la memoria caché de respuesta, HTTP.sys envía la respuesta almacenada en caché directamente desde el modo kernel. Algunas plataformas de aplicaciones web, como ASP.NET, proporcionan mecanismos para permitir que se almacene en caché cualquier contenido dinámico en la memoria 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 se deben optimizar para obtener un rendimiento óptimo. Por lo tanto, la optimización de IIS 10.0 para una carga de trabajo específica incluye la configuración siguiente:
HTTP.sys y la memoria caché en modo kernel asociada
Procesos de trabajo e IIS en modo de usuario, incluida la configuración del grupo de aplicaciones
Determinados parámetros de optimización que afectan al rendimiento
En las secciones siguientes, se describe cómo configurar los aspectos del modo kernel y del 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 categorías generales: administración de caché y administración de conexiones y solicitudes. Todas las configuraciones del Registro se almacenan en la siguiente entrada del Registro:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters
Nota Si el servicio HTTP ya está en ejecución, debe reiniciarlo para que los cambios surtan efecto.
Configuración de la administración de caché
Una ventaja que proporciona HTTP.sys es una memoria caché en modo kernel. Si la respuesta está en la memoria caché en modo kernel, es posible satisfacer por completo una solicitud HTTP desde el modo kernel, lo que reduce significativamente el costo de CPU de controlar 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 de la memoria caché solo es útil cuando se usa. Sin embargo, la entrada siempre consume memoria física, independientemente de si se usa o no la entrada. Debe evaluar la utilidad de un elemento de la memoria caché (el ahorro de poder servirlo desde la memoria caché) y su costo (la memoria física ocupada) durante la duración de la entrada teniendo en cuenta los recursos disponibles (CPU y memoria física) y los requisitos de la carga de trabajo. HTTP.sys intenta mantener en la memoria caché solo elementos útiles a los que se accede activamente, pero puede aumentar el rendimiento del servidor web ajustando la memoria caché de HTTP.sys para cargas de trabajo específicas.
A continuación, se muestran algunas opciones útiles para la memoria caché en modo kernel de HTTP.sys:
Valor predeterminado de UriEnableCache: 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 memoria caché debe permanecer habilitada. Considere la posibilidad de deshabilitar la memoria caché si espera un almacenamiento en caché muy bajo de respuestas y fragmentos.
Valor predeterminado de UriMaxCacheMegabyteCount: 0
Un valor distinto de cero especifica la memoria máxima que está disponible para la memoria caché en modo kernel. El valor predeterminado (0) permite al sistema ajustar automáticamente la cantidad de memoria disponible para la memoria caché.
Nota Especificar el tamaño establece solo el máximo y es posible que el sistema no permita que la memoria caché crezca hasta el tamaño máximo establecido.
Â
Valor predeterminado de UriMaxUriBytes: 262 144 bytes (256 KB)
Tamaño máximo de una entrada de la memoria caché en modo kernel. Las respuestas o fragmentos mayores que este valor no se almacenan en caché. Si tiene suficiente memoria, considere la posibilidad de aumentar el límite. Si la memoria es limitada y las entradas grandes desplazan a las pequeñas, puede ser útil reducir el límite.
Valor predeterminado de UriScavengerPeriod: 120 segundos
La memoria caché de HTTP.sys se examina periódicamente mediante un limpiador y se quitan las entradas a las que no se ha accedido entre los exámenes del limpiador. Si se establece el período del limpiador en un valor alto, se reduce el número de exámenes del limpiador. Sin embargo, el uso de memoria de la caché puede aumentar porque las entradas más antiguas y a las que se accede con menos frecuencia pueden permanecer en la memoria caché. Establecer el período demasiado bajo provoca exámenes del limpiador más frecuentes y puede dar lugar a demasiados vaciados y renovaciones de la caché.
Configuración de la administración de solicitudes y conexiones
En Windows Server 2022, HTTP.sys administra automáticamente las conexiones. Las siguientes configuraciones del Registro ya no se utilizan:
MaxConnections
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\MaxConnectionsIdleConnectionsHighMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsHighMarkIdleConnectionsLowMark
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleConnectionsLowMarkIdleListTrimmerPeriod
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\IdleListTrimmerPeriodRequestBufferLookasideDepth
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Http\Parameters\RequestBufferLookasideDepthInternalRequestLookasideDepth
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, o los cmdlets de PowerShell WebAdministration o IISAdministration para cambiarlas. 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 ni del servidor de aplicaciones web. Para obtener más información sobre el archivo applicationHost.config, consulte Introducción a ApplicationHost.config.
Configuración ideal de CPU para hardware NUMA
A partir de Windows Server 2016, IIS 10.0 admite la asignación automática de CPU ideal para los subprocesos del grupo de subprocesos para mejorar el rendimiento y la escalabilidad en el hardware NUMA. Esta característica está habilitada de manera predeterminada y se puede configurar mediante 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 su mejor esfuerzo para distribuir uniformemente los subprocesos del grupo de subprocesos de IIS entre 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 ideal de CPU es diferente de la configuración de asignación de nodos NUMA del proceso de trabajo (numaNodeAssignment y numaNodeAffinityMode) presentada en Configuración de CPU para un grupo de aplicaciones. La configuración ideal de CPU afecta a cómo 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 memoria caché en modo de usuario
En esta sección, se describen las opciones de configuración que afectan al comportamiento del almacenamiento en caché en IIS 10.0. La memoria caché en modo de usuario se implementa como un módulo que escucha los eventos globales de almacenamiento en caché que genera la canalización integrada. Para deshabilitar completamente la memoria 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 de applicationHost.config.
system.webServer/caching
| Atributo | Descripción | Valor predeterminado |
|---|---|---|
| Habilitada | Deshabilita la memoria caché de IIS en modo de usuario cuando se establece en False. Cuando la tasa de aciertos de caché es muy pequeña, puede deshabilitar la memoria caché por completo para evitar la sobrecarga asociada a la ruta de acceso del código de caché. Deshabilitar la memoria caché en modo de usuario no deshabilita la memoria caché en modo kernel. | True |
| enableKernelCache | Deshabilita la memoria caché en modo kernel cuando se establece en False. | True |
| maxCacheSize | Limita el tamaño de la memoria 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 frente a la cantidad de RAM o el espacio de direcciones del proceso de IIS. | 0 |
| maxResponseSize | Almacena en caché los archivos hasta el tamaño especificado. El valor real depende del número y tamaño de los archivos más grandes del conjunto de datos frente a la RAM disponible. El almacenamiento en caché de archivos grandes y solicitados con frecuencia puede reducir el uso de CPU, el acceso al disco y las latencias asociadas. | 262 144 |
Configuración del comportamiento de compresión
A partir de la versión 7.0, IIS comprime el contenido estático de manera predeterminada. Además, la compresión del contenido dinámico está habilitada de manera predeterminada cuando se instala DynamicCompressionModule. La compresión reduce el uso de ancho de banda, pero aumenta el uso de CPU. Si es posible, el contenido comprimido se almacena en la memoria caché en modo kernel. A partir de la versión 8.5, IIS permite controlar la compresión de forma independiente para el contenido estático y dinámico. Normalmente, el contenido estático hace 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, por ejemplo, páginas de ASP.NET. Puede personalizar la clasificación de cualquier extensión determinada 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.
system.webServer/httpCompression
| Atributo | Descripción | Valor predeterminado |
|---|---|---|
| staticCompression-EnableCpuUsage staticCompression-DisableCpuUsage dynamicCompression-EnableCpuUsage dynamicCompression-DisableCpuUsage |
Habilita o deshabilita la compresión si el porcentaje actual de uso de CPU supera 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 se habilita si la CPU cae por debajo del umbral de habilitación. |
50, 100, 50 y 90 respectivamente |
| directory | Especifica el directorio en el que se van a guardar temporalmente y almacenar 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 Temporary Compressed Files |
| 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. | True |
| 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 | Valor predeterminado |
|---|---|---|
| doStaticCompression | Especifica si se comprime el contenido estático. | Verdadero |
| doDynamicCompression | Especifica si se comprime el contenido dinámico. | True |
Nota
En el caso de los servidores que ejecutan IIS 10.0 y que tienen un uso promedio bajo de CPU, considere la posibilidad de habilitar la compresión para el contenido dinámico, especialmente si las respuestas son grandes. Esto se debe hacer primero en un entorno de prueba para evaluar el efecto en el uso de CPU con respecto a la línea base.
Ajuste de la lista de documentos predeterminada
El módulo de documento predeterminado controla las solicitudes HTTP para la raíz de un directorio y las traduce en solicitudes de un archivo específico, como Default.htm o Index.htm. En promedio, alrededor del 25 % de todas las solicitudes de Internet pasan por la ruta de acceso del documento predeterminado. Esto varía significativamente para sitios individuales. Cuando una solicitud HTTP no especifica un nombre de archivo, el módulo de documento predeterminado busca en la lista de documentos predeterminados permitidos cada nombre del sistema de archivos. Esto puede afectar negativamente al rendimiento, especialmente si acceder al contenido requiere realizar un recorrido de ida y vuelta de red o tocar un disco.
Puede evitar la sobrecarga si deshabilita de forma selectiva los documentos predeterminados y reduce u ordena la lista de documentos. En el caso de los sitios web que usan un documento predeterminado, debe reducir la lista solo a los tipos de documento predeterminados que se usan. Además, ordene la lista para 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 del documento predeterminado en direcciones URL específicas 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 cuando son necesarios y establece la lista en el nombre de archivo correcto para cada dirección 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.
system.webServer/defaultDocument
| Atributo | Descripción | Valor predeterminado |
|---|---|---|
| enabled | Especifica que los documentos predeterminados están habilitados. | True |
Elemento <files> |
Especifica los nombres de archivo configurados como documentos predeterminados. | La lista predeterminada es Default.htm, Default.asp, Index.htm, Index.html, Iisstart.htm y 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 procesamiento posterior.
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 y a una unidad de registro dedicada para evitar la contención entre las actividades del sistema y las actividades de registro.
system.applicationHost/log
| Atributo | Descripción | Valor 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 | Valor predeterminado |
|---|---|---|
| enabled | Especifica si está habilitado el registro binario central. | False |
| directory | Especifica el directorio en el que se escriben las entradas del registro. | %SystemDrive%\inetpub\logs\LogFiles |
Ajustes de aplicaciones y sitios
La siguiente configuración está relacionada con el ajuste del grupo de aplicaciones y el sitio.
system.applicationHost/applicationPools/applicationPoolDefaults
| Atributo | Descripción | Valor predeterminado |
|---|---|---|
| queueLength | Indica a 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 aumentarlo para las aplicaciones que se comunican con almacenes de datos de back-end de alta latencia si se observan errores 503. |
1000 |
| enable32BitAppOnWin64 | Cuando es True, permite que una aplicación de 32 bits se ejecute en un equipo que tiene 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 y los tamaños de 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. |
False |
system.applicationHost/sites/VirtualDirectoryDefault
| Atributo | Descripción | Valor 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 /<nombre>.htm sea un directorio virtual, no debe buscar un archivo de configuración. Omitir las operaciones de archivo 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. | Verdadero |
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 pertinente para el módulo. Esto sucede independientemente de si el módulo debe realizar algún trabajo. Puede ahorrar ciclos de CPU y memoria quitando todos los módulos que no sean pertinentes para un sitio web determinado.
Un servidor web optimizado para archivos estáticos simples podría incluir solo los cinco módulos siguientes: UriCacheModule, HttpCacheModule, StaticFileModule, AnonymousAuthenticationModule y HttpLoggingModule.
Para quitar módulos del archivo applicationHost.config, quite todas las referencias al módulo de las secciones system.webServer/handlers y system.webServer/modules, además de quitar la declaración del módulo en system.webServer/globalModules.
Configuración de ASP clásico
El costo principal de procesar una solicitud de ASP clásico 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 de ASP clásico de IIS puede almacenar en caché los motores de scripts en memoria y las 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 relacionados con la CPU.
Las siguientes opciones se usan para configurar la memoria caché de plantillas de ASP clásico y la memoria caché del motor de scripts, y no afectan a la configuración de ASP.NET.
system.webServer/asp/cache
| Atributo | Descripción | Valor predeterminado |
|---|---|---|
| diskTemplateCacheDirectory | Nombre del directorio que usa ASP para almacenar las plantillas compiladas cuando se desborda la caché en memoria. Recomendación: establecer en un directorio que no se use en gran medida, 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 Compiled Templates |
| maxDiskTemplateCacheFiles | Especifica el número máximo de plantillas ASP compiladas que se pueden almacenar en caché en el disco. Recomendación: establecer 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 memoria. Recomendación: establecer al menos en el número de scripts ASP solicitados con frecuencia por un grupo de aplicaciones. Si es posible, establecer 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 memoria. Recomendación: establecer al menos en el número de scripts ASP solicitados con frecuencia por un grupo de aplicaciones. Si es posible, establecer en tantos motores de scripts como permita el límite de memoria. |
250 |
system.webServer/asp/limits
| Atributo | Descripción | Valor predeterminado |
|---|---|---|
| processorThreadMax | Especifica el número máximo de subprocesos de trabajo que puede crear ASP por cada procesador. Aumentar si la configuración actual no es suficiente para controlar la carga, lo que puede provocar errores cuando atiende solicitudes o provocar un uso insuficiente de los recursos de CPU. | 25 |
system.webServer/asp/comPlus
| Atributo | Descripción | Valor predeterminado |
|---|---|---|
| executeInMta | Establecer en True si se detectan errores mientras IIS atiende contenido de ASP. Esto puede ocurrir, por ejemplo, al hospedar 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. | False |
Configuración de la simultaneidad en ASP.NET
ASP.NET 3.5
De manera 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 para mejorar el rendimiento general. Puede cambiar esta configuración en el archivo aspnet.config:
<system.web>
<applicationPool maxConcurrentRequestsPerCPU="5000"/>
</system.web>
La siguiente configuración es útil para usar completamente los recursos de un sistema:
maxConcurrentRequestPerCpu Valor predeterminado: 5000
Esta configuración limita el número máximo de solicitudes de ASP.NET simultáneamente en ejecución en un sistema. El valor predeterminado es conservador para reducir el consumo de memoria de las aplicaciones ASP.NET. Considere la posibilidad de aumentar este límite en 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 puesta en cola o de solicitud debido a que se superan los límites de la 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 de la operación asincrónica. La configuración se puede cambiar en el archivo aspnet.config.
<system.web>
<applicationPool percentCpuLimit="90" percentCpuLimitMinActiveRequestPerCpu="100"/>
</system.web>
- percentCpuLimit (Valor predeterminado: 90) Las solicitudes asincrónicas tienen algunos problemas de escalabilidad cuando se coloca una carga enorme (más allá de la capacidad del hardware) en este 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 GC haya movido los objetos a la generación 1 o 2. Cuando esto sucede, el aumento de la carga mostrará un aumento en las solicitudes por segundo (rps) hasta un punto. Una vez que pasemos ese punto, el tiempo invertido en la recolección de elementos no utilizados comenzará a convertirse en un problema y las rps comenzarán a bajar, teniendo un efecto negativo en el escalado. Para corregir el problema, cuando el uso de CPU supera la configuración percentCpuLimit, las solicitudes se enviarán a la cola nativa de ASP.NET.
- percentCpuLimitMinActiveRequestPerCpu (Valor predeterminado: 100) La limitación de CPU (configuración percentCpuLimit) no se basa en el número de solicitudes, sino en lo costosas que son. Como resultado, podría haber solo unas pocas solicitudes que consumen mucha CPU, lo que provocaría una copia de seguridad en la cola nativa sin ninguna manera de vaciarla aparte de las solicitudes entrantes. Para resolver este problema, se puede usar percentCpuLimitMinActiveRequestPerCpu para asegurarse de que se atienda un número mínimo de solicitudes antes de que se inicie la limitación.
Proceso de trabajo y opciones de reciclaje
Puede configurar opciones para reciclar los procesos de trabajo de IIS y proporcionar soluciones prácticas a situaciones o eventos agudos sin necesidad de intervención ni 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 inactivos o que no responden. En condiciones normales, es posible que las opciones de reciclaje no sean necesarias y el reciclaje se puede desactivar, o bien se puede configurar el sistema para reciclar muy poco frecuentemente.
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, como el uso de memoria, un número fijo de solicitudes y un período de tiempo fijo. Cuando se recicla un proceso de trabajo, las solicitudes en cola y en ejecución se purgan y se inicia simultáneamente un nuevo proceso para atender nuevas solicitudes. El elemento recycling/periodicRestart es por cada aplicación, lo que significa que cada atributo de la tabla siguiente se particiona por aplicación.
system.applicationHost/applicationPools/ApplicationPoolDefaults/recycling/periodicRestart
| Atributo | Descripción | Valor predeterminado |
|---|---|---|
| memoria | Habilita el reciclaje de procesos si el consumo de memoria virtual supera el límite especificado en kilobytes. Se trata de 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 con errores debido a errores de memoria insuficiente. | 0 |
| privateMemory | Habilita el reciclaje de procesos si las asignaciones de memoria privada superan un límite especificado en kilobytes. | 0 |
| Solicitudes | Habilita el reciclaje de procesos después de un número determinado de solicitudes. | 0 |
| time | Habilita el reciclaje de procesos después de un período de tiempo especificado. | 29:00:00 |
Ajuste dinámico de la salida de páginas de los 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 finalización, que existía desde IIS 7).
El propósito principal de las características de salida de páginas de los procesos de trabajo inactivos y terminación de los trabajos inactivos es conservar el uso de memoria en el servidor, ya que un sitio puede consumir mucha memoria incluso si está simplemente a la escucha. En función de la tecnología empleada en el sitio (contenido estático frente a ASP.NET frente a otros marcos), la memoria usada puede ir desde aproximadamente 10 MB a cientos de MB, lo que significa que si el servidor está configurado con muchos sitios, averiguar la configuración más eficaz para los sitios puede mejorar considerablemente el rendimiento de los sitios activos y suspendidos.
Antes de entrar en detalles, debemos tener en cuenta que si no hay restricciones de memoria, es probable que sea mejor establecer simplemente los sitios para que nunca se suspendan o finalicen. Después de todo, tiene poco valor interrumpir 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 por otra razón, establecer el sitio para finalizar en caso de inactividad puede ser una alternativa rápida y desordenada para corregir el error de código. Esto no es algo que se recomiende, pero en una crisis, puede ser mejor usar esta característica como un mecanismo de limpieza mientras que una solución más permanente está en camino.
Otro factor que se debe tener en cuenta es que si el sitio usa una gran cantidad de memoria, el propio proceso de suspensión tiene un peaje, ya que el equipo tiene que escribir los datos utilizados por el proceso de trabajo en el disco. Si el proceso de trabajo usa un gran fragmento de memoria, suspenderlo podría ser más costoso que el costo de tener que esperar a que se inicie la copia de seguridad.
Para aprovechar las ventajas de la característica de suspensión de procesos de trabajo, debe revisar los sitios de cada grupo de aplicaciones y decidir cuál se debe suspender, cuál se debe finalizar y cuál debe estar activo indefinidamente. Para cada acción y cada sitio, debe averiguar el período de tiempo de espera ideal.
Idealmente, los sitios que configurará para la suspensión o finalización son aquellos que tienen visitantes todos los días, pero no lo suficiente para garantizar mantenerlo activo todo el tiempo. Por lo general, estos son sitios con alrededor de 20 visitantes únicos al día o menos. Puede analizar los patrones de tráfico mediante 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 el recuento de solicitudes diarias no refleje con precisión los patrones de tráfico reales. Para obtener una lectura más precisa, también puede usar una herramienta, como Microsoft Excel, para calcular el tiempo medio entre solicitudes. Por ejemplo:
| Number | URL de solicitud | Hora de la solicitud | Delta |
|---|---|---|---|
| 1 | /SourceSilverLight/Geosource.web/grosource.html | 10:01 | |
| 2 | /SourceSilverLight/Geosource.web/sliverlight.js | 10:10 | 0:09 |
| 3 | /SourceSilverLight/Geosource.web/clientbin/geo/1.aspx | 10:11 | 0:01 |
| 4 | /lClientAccessPolicy.xml | 10:12 | 0:01 |
| 5 | / SourceSilverLight/GeosourcewebService/Service.asmx | 10:23 | 0:11 |
| 6 | / SourceSilverLight/Geosource.web/GeoSearchServer...¦. | 11:50 | 1:27 |
| 7 | /rest/Services/CachedServices/Silverlight_load_la...¦ | 12:50 | 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 |
Sin embargo, la parte dura es averiguar qué configuración se debe aplicar para que tenga sentido. En nuestro caso, el sitio obtiene una serie de solicitudes de los usuarios y la tabla anterior muestra que hubo 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 se 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 hace que sea un candidato ideal para la suspensión del proceso de trabajo, ya que, durante la mayor parte del tiempo, el sitio está inactivo, por lo que al suspenderse se conservarían los recursos y permitiría a los usuarios acceder al sitio casi al instante.
Una nota final y muy importante sobre esto es que el rendimiento del disco es fundamental para esta característica. Dado que el proceso de suspensión y reactivación implica la escritura y lectura de una gran cantidad de datos en el disco duro, se recomienda usar 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 una (si el propio sistema operativo no está instalado en el SSD, configure el sistema operativo para mover el archivo de paginación al SSD).
Tanto si usa un SSD como si no, también se recomienda corregir el tamaño del archivo de paginación para dar cabida a la escritura de los datos de la salida de páginas en él sin cambiar el tamaño del archivo. El cambio de tamaño de los archivos de paginación se puede producir cuando el sistema operativo necesita almacenar datos en el archivo de paginación, ya que, de manera predeterminada, Windows está configurado para ajustar automáticamente su tamaño en función de las necesidades. 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 fijado previamente, debe calcular su tamaño ideal, que depende del número de sitios que se vayan a suspender y de la cantidad de memoria que consumen. Si el promedio es de 200 MB para un proceso de trabajo activo y tiene 500 sitios en los servidores que se van a suspender, el archivo de paginación debe tener al menos (200 * 500) MB sobre el tamaño base del archivo de paginación (por lo tanto, base + 100 GB en nuestro ejemplo).
Nota
Cuando se suspendan los sitios, 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 aproximadamente 3 GB. Sin embargo, en la realidad es probable que nunca los suspenda todos al mismo tiempo.
Parámetros de ajuste de Seguridad de la capa de transporte
El uso de Seguridad de la capa de transporte (TLS) impone un costo adicional de CPU. El componente más caro de TLS es el costo de establecer una sesión porque implica un protocolo de enlace completo. La reconexión, el cifrado y el descifrado también se agregan al costo. Para mejorar el rendimiento de TLS, haga lo siguiente:
Habilite las conexiones HTTP persistentes para las sesiones TLS. Esto elimina los costos de establecimiento de sesión.
Reutilice las sesiones cuando sea adecuado, especialmente con el tráfico no persistente.
Aplique de forma selectiva 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 usan más tiempo de CPU.
- Es posible que no sea necesario cifrar todos los componentes. Sin embargo, la combinación de HTTP no seguro y HTTPS podría dar lugar a una advertencia emergente que indique 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 teniendo en cuenta el uso de recursos y el rendimiento.
Directrices de optimización del código administrado
El modelo de canalización integrada de 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 bien pueden sustituir 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 el 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 significativo de CPU debido a la serialización de datos entre el código nativo y el administrado. Si es posible, debe establecer la opción 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 de ASP.NET o aprovechar la característica de inicialización de aplicaciones de IIS para preparar la aplicación.
Si no es necesario el estado de sesión, asegúrese de desactivarlo para cada página.
Si hay muchas operaciones relacionadas con la E/S, intente usar la versión asincrónica de las API pertinentes, lo que le proporcionará una escalabilidad mucho mejor.
El uso correcto de la caché de salida también aumentará el rendimiento del sitio web.
Al ejecutar varios hosts que contienen scripts de ASP.NET en modo aislado (un grupo de aplicaciones por sitio), supervise el uso de memoria. Asegúrese de que el servidor tenga suficiente RAM para el número esperado de grupos de aplicaciones que se ejecutan simultáneamente. Considere la posibilidad de usar 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 memoria caché
La instalación de un filtro que no tiene en cuenta la memoria caché de HTTP hace que IIS deshabilite completamente el almacenamiento en caché, lo que da lugar a un rendimiento deficiente. Los filtros ISAPI escritos 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. La creación y eliminación frecuente de procesos de CGI implica una sobrecarga significativa. Entre las mejores alternativas, se incluyen el uso de FastCGI, scripts de aplicación ISAPI y scripts de ASP o ASP.NET. El aislamiento está disponible para cada una de estas opciones.