IIS 7.0
Las diez principales mejoras de rendimiento en IIS 7.0
Mike Volodarsky
De un vistazo:
- Minimizar el tamaño de la aplicación
- Reducir los costos de ancho de banda
- Usar las capacidades de caché mejoradas
Contenido
Servidores web más eficaces
Basarse en un sistema operativo eficaz
Topologías de aplicación especializadas
Compatibilidad con aplicaciones mejorada
Aumento de la densidad de aplicaciones
Reducción de ancho de banda mediante compresión
Limitación de velocidad de bits de medios
Almacenamiento en caché de los resultados
Conversión del código ISAPI en módulos de IIS 7.0
Extensibilidad de servidor
Conclusión
Cuando me reúno con las compañías que planean adoptar IIS 7.0, una cuestión que surge inevitablemente es si al cambiar a IIS 7.0 se mejorará el rendimiento de los servidores o las aplicaciones. La
respuesta por lo general es que sí, pero no hay que sorprenderse si no se ven mejoras de rendimiento al migrar por primera vez las aplicaciones a IIS 7.0.
Para comprender esto, es necesario entender la naturaleza de la última versión. IIS 6.0 fue una versión de ingeniería concebida para conseguir tres cosas: mayor seguridad, mayor confiabilidad y mejor rendimiento. Por el contrario, IIS 7.0 es una versión de plataforma. Su finalidad es convertir el núcleo de servidor web base de alta calidad de su antecesor en una plataforma modular y ampliable con compatibilidad para los escenarios actuales de implementación y administración.
Muchos de los cambios de arquitectura y las nuevas características pueden tener una repercusión negativa en el rendimiento del servidor web. Por ejemplo, uno de los cambios clave divide las rutas de acceso de código de servidor web plenamente integradas en módulos independientes que no obtienen un tratamiento especial del servidor web. No obstante, gracias a la gran cantidad de trabajo que ha realizado el equipo de IIS, IIS 7.0 tiene el mismo rendimiento que su antecesor y lo supera en determinadas áreas. Como puedo afirmar personalmente a partir de mi trabajo en el núcleo de servidor web y la canalización integrada, la consecución de esto requirió mucha inventiva en el diseño y trabajo duro en la implementación del producto.
A pesar de todo, IIS 7.0 tiene un potencial mucho mayor para ofrecer mejoras de rendimiento importantes y reducir los costos relacionados con el rendimiento para la granja de servidores que cualquier otra versión de IIS en el pasado.
Estas ventajas no se van a apreciar necesariamente con sólo migrar a IIS 7.0, pero sí en algunos entornos. Por ejemplo, Microsoft.com apreció una mejora del 10% en la eficacia de CPU (se puede encontrar el análisis completo en el blog del equipo de Microsoft.com en go.microsoft.com/fwlink/?LinkId=122497). También pueden observarse mejoras destacadas en áreas específicas, incluido SSL (capa de sockets seguros) y autenticación de Windows® (ambos se llevan a cabo en el kernel), y una mejor escalabilidad vertical en equipos con varios núcleos y múltiples procesadores.
No obstante, la eficacia real de IIS 7.0 no procede de las mejoras de rendimiento incrementales en las características existentes. En vez de eso, las mejoras proceden de las nuevas capacidades de las que se debe hacer un uso activo. Con frecuencia estas capacidades están arraigadas en la flexibilidad y la naturaleza extensible de la plataforma y en las nuevas características de rendimiento. En este artículo, mostraré 10 de los orígenes más importantes de las mejoras de rendimiento que se pueden liberar con el cambio a IIS 7.0.
Servidores web más eficaces
La capacidad de implementar servidores IIS 7.0 eficaces se deriva de la estructura modular del servidor. Prácticamente todas sus características de servidor web están implementadas como componentes modulares que se pueden agregar o quitar individualmente. De este modo, puede quitar cualquier característica de servidor que no sea necesaria para el funcionamiento de una aplicación, con lo que se aprecian ventajas importantes, incluida un área de superficie de ataque considerablemente reducida, un menor espacio operativo y un rendimiento mejorado.
El conjunto de características de servidor de IIS 7.0 completo contiene 44 módulos, incluidos módulos IIS nativos y módulos ASP.NET que proporcionan servicios para la canalización integrada. Estos módulos ofrecen servicios tales como la autenticación (módulos Autenticación de Windows y Autenticación de texto implícita), compatibilidad de marco de aplicaciones (módulo FastCGI), servicios de aplicación (módulo Estado de sesión), seguridad (módulo Filtro de solicitudes) y rendimiento (módulo Caché de resultados). Por lo que un servidor web mínimo que tiene que servir contenido estático puede ser funcional con sólo dos módulos.
La sobrecarga de los módulos innecesarios puede ser bastante importante (por ejemplo, en el caso de los módulos de registro de solicitudes y seguimiento de solicitudes con error). Al quitar estos módulos de los entornos en los que no se necesitan se puede producir un mayor rendimiento total y respuestas más rápidas que reduzcan las métricas de tiempo al primer byte (TTFB) y tiempo al último byte (TTLB) para la carga de trabajo del servidor.
En la figura 1 se muestran los resultados de una simple prueba de rendimiento de un archivo HTML (carga de trabajo estática) y una página ASP.NET del tipo "hola a todos" (carga de trabajo ASP.NET) cuando se configuran con el conjunto completo de características, el conjunto predeterminado de características para dicha carga de trabajo y el conjunto imprescindible de características necesarias para la carga de trabajo. Incluso si la mayoría de las características no esenciales ya están deshabilitadas en la configuración completa, al quitarlas totalmente de la configuración mínima se obtiene un incremento considerable del rendimiento tanto para la carga de trabajo estática como para la carga de trabajo ASP.NET.
Figura 1 Tasas de rendimiento de la carga de trabajo estática y la carga de trabajo ASP.NET en tres configuraciones distintas con 100 clientes simultáneos (haga clic en la imagen para ampliarla)
Además, puede ver mejoras en el espacio de memoria y la mayor densidad de sitio, especialmente en entornos de hospedaje compartido o en los casos donde se usa una gran cantidad de procesos de trabajo. Normalmente se logra con la carga de menos DLL en cada proceso y con la eliminación de las asignaciones de memoria que se producen durante la inicialización de módulos y el procesamiento de solicitudes. En la figura 2 se muestra el uso de la memoria (bytes privados del proceso de trabajo de IIS) en la misma prueba de rendimiento. Aunque las mejoras no son muy destacadas en este ejemplo, el incremento está en consonancia con las expectativas, ya que la sobrecarga de dominio de aplicaciones de ASP.NET es relativamente más alta que el ahorro de línea de base que proporcionan los módulos que se han quitado.
Figura 2 Uso de memoria (bytes privados) de las cargas de trabajo estática y ASP.NET en tres configuraciones distintas con 100 clientes simultáneos (haga clic en la imagen para ampliarla)
IIS 7.0 proporciona control adicional de los módulos que están habilitados en el nivel de aplicación, así como control del uso de módulos según la carga de trabajo mediante condiciones previas de módulo. Aunque esto requiere una configuración avanzada, puede proporcionar ventajas adicionales en entornos de varios sitios o para aplicaciones que admitan múltiples cargas de trabajo diferenciadas.
Pero cuidado, la determinación de la funcionalidad necesaria puede resultar complicada. Debe tener en cuenta no sólo la funcionalidad mínima necesaria para admitir el marco de aplicación, sino también cualquiera de las características adicionales en las que se pueda basar la aplicación indirectamente. Por ejemplo, la aplicación puede depender de métodos de autenticación específicos o estar basada en semánticas de autorización proporcionadas por diferentes características de IIS; en tal caso, al quitarlas se puede ver afectada negativamente la seguridad de la aplicación. Del mismo modo, la aplicación se puede basar en algunos de los módulos a efectos funcionales o de rendimiento; en tal caso, al quitarlos se puede producir un comportamiento incorrecto o una pérdida de rendimiento.
Basarse en un sistema operativo eficaz
Windows Server® 2008 también proporciona división por componentes en el nivel de sistema operativo que puede usar para reducir aún más el área de superficie del servidor web. Server Core es una opción de instalación mínima para el sistema operativo Windows Server 2008 y contiene un conjunto mínimo de subsistemas principales del sistema operativo. Server Core es un entorno ideal para servidores web IIS 7.0 eficaces.
Pero, al evaluar Server Core, tenga en cuenta que algunas limitaciones pueden afectar a su aplicación. Server Core no ofrece compatibilidad con Microsoft® .NET Framework, lo que significa que no hay ASP.NET, extensibilidad .NET para IIS ni Administrador de IIS. Además, las tareas de administración local requerirán herramientas de la línea de comandos ya que no hay Microsoft Management Console (MMC). Desde el punto de vista del rendimiento, si ya ha aprovechado correctamente la división en componentes de IIS, puede que no aprecie diferencias en el espacio de memoria o el rendimiento de la carga de trabajo de la aplicación en Server Core con respecto a una implementación completa de Windows Server. Esto se debe a que el trabajo que realiza IIS y la aplicación es el mismo en ambas plataformas. No obstante, hay un lugar donde se notarán diferencias: el tamaño general del servidor, tanto en términos de espacio en disco como en uso de memoria.
Como ejemplo, en la figura 3 se muestra la diferencia en tamaño después de realizar la prueba de carga de trabajo estática en una configuración de Windows Server 2008 completa y en Server Core. Aunque el tamaño de IIS es prácticamente idéntico en ambos casos, el menor espacio de sistema operativo general de Server Core permite que la carga de trabajo se admita con considerablemente menos memoria. De hecho, el menor tamaño puede permitir la implementación de la carga de trabajo de aplicación en hardware menos eficaz, centrándose en las demandas de procesamiento de la aplicación y no en el entorno operativo. Evidentemente, esto convierte a Server Core en una opción excelente para entornos virtualizados.
Figura 3 Espacio de memoria de Windows Server 2008 completo con respecto a Server Core después de realizar la prueba de carga de trabajo estática (haga clic en la imagen para ampliarla)
Topologías de aplicación especializadas
Al efectuar la optimización para cargas de trabajo de aplicación, se puede separar la carga de trabajo en partes diferenciadas. Por ejemplo, en vez de ejecutar la aplicación en una granja de 30 servidores web idénticos, puede ejecutarla en 10 servidores web, 5 servidores de aplicaciones y 3 servidores proxy que realicen el almacenamiento en caché y la compresión.
Hay varios motivos por los que funciona esta especialización. En primer lugar, el rendimiento de numerosas cargas de trabajo de aplicación depende en gran medida de una serie de recursos compartidos, como la memoria, que se pueden disputar varias partes de la aplicación. La disputa de estos recursos puede crear cuellos de botella que impidan que cada servidor se pueda usar por completo en los demás recursos. Al separar las partes de la aplicación se les ofrece acceso inmediato a los recursos que de otra manera se disputarían, lo que redunda en una mayor eficacia en el mismo conjunto de recursos de hardware.
En segundo lugar, la especialización puede habilitar que la aplicación logre una mayor localidad de caché, por lo que se mejora el rendimiento. Esto incluye el almacenamiento en caché de bajo nivel, como el búfer de traducción de direcciones (TLB) en memoria virtual, la caché del sistema de archivos y otras cachés de sistema operativo y de aplicaciones. Otro origen de ganancia de localidad se encuentra en la CPU. Mediante la reducción del número de actividades paralelas que tienen lugar al centrarse únicamente en una parte específica de la aplicación, ésta puede reducir el número de cambios de contextos y maximizar el trabajo desempeñado por la CPU.
En tercer lugar, la especialización habilita la optimización específica de carga de trabajo, con lo que cada parte de la aplicación funciona de un modo más eficaz. Muchas de estas optimizaciones no son posibles cuando toda la aplicación se encuentra en el mismo servidor debido a las necesidades en conflicto de las diferentes partes de la aplicación.
Un lugar habitual donde se produce esto es en la configuración de subprocesos de IIS y ASP.NET, que afecta considerablemente a la simultaneidad y afecta de forma indirecta al uso de memoria, latencia y rendimiento para numerosas aplicaciones. La carga de trabajo de archivos estática de IIS es muy asincrónica y requiere un elevado límite de solicitudes simultáneas, pero prospera en un número muy bajo de subprocesos disponibles. Por otro lado, muchas de las características de ASP.NET son sincrónicas, con un bloqueo largo y requieren un elevado número de subprocesos, mientras que otras requieren un límite de simultaneidad menor para reducir la repercusión en la memoria. Al separar la carga de trabajo estática y desglosar las partes de la canalización de procesamiento de solicitudes en un proceso o servidor independiente, se puede optimizar la simultaneidad de cada carga de trabajo individual.
Por último, la especialización puede habilitar una mayor escalabilidad general al permitir que la aplicación escale cargas de trabajo discretas o partes de aplicación independientes entre sí. Esto puede habilitar que la topología de aplicación ofrezca mayor capacidad y redundancia donde más se necesite, en vez de requerir que se aplique la misma plantilla a toda la aplicación. En este modelo, los recursos especializados pueden ser servidores físicos, servidores virtuales o incluso grupos de aplicaciones en el mismo equipo.
Al evaluar las ventajas posibles de la especialización en su topología de aplicación, empiece por buscar los cuellos de botella de procesamiento o de uso intensivo de los recursos en su aplicación. Estas áreas deben ser los primeros candidatos para la especialización ya que pueden proporcionar un potencial importante para la optimización cuando están aisladas y porque exigirán el máximo escalado en horizontal. A continuación, evalúe si el aislamiento habilita al resto de la aplicación para usar los recursos de un modo más eficaz. Finalmente, deberá evaluar la sobrecarga del mecanismo de conectividad necesario para combinar los componentes de la aplicación.
Compatibilidad con aplicaciones mejorada
IIS 7.0 incluye compatibilidad ampliada para los marcos de aplicaciones mediante FastCGI, un protocolo abierto que admiten muchos marcos de aplicaciones de código abierto que, de lo contrario, no podrían admitir la integración nativa estable y de alto rendimiento con IIS. A diferencia del protocolo de interfaz CGI, que ha admitido IIS durante mucho tiempo, FastCGI proporciona un rendimiento mucho mayor en la plataforma Windows. Esto se debe principalmente a la arquitectura de proceso reutilizable de FastCGI, que elimina la sobrecarga de la creación intensiva de procesos por solicitud, lo que permite a los clientes aprovechar las conexiones persistentes.
Si admite marcos de aplicaciones en IIS con CGI u otro mecanismo, puede lograr un rendimiento mejorado (y, en algunos casos, estabilidad) si cambia al protocolo FastCGI.
El primer marco de aplicaciones que aprovecha esta compatibilidad es PHP. De hecho, el equipo de IIS ha trabajado directamente con Zend Technologies para asegurarse de que la implementación FastCGI de IIS funciona bien con PHP y permite mejoras de rendimiento en el marco PHP en Windows. (Para obtener más información acerca del proyecto, consulte la publicación en mi blog en go.microsoft.com/fwlink/?LinkId=122509.) Si tiene una combinación de tecnologías de servidor web que incluya aplicaciones ASP o ASP.NET ejecutándose en IIS y PHP u otros marcos de aplicaciones compatibles con FastCGI que usen otras tecnologías, podrá consolidar estas aplicaciones en la plataforma IIS 7.0.
El cambio de PHP y otros marcos de aplicaciones a IIS 7.0 y FastCGI le permitirá aprovechar las características de IIS 7.0, incluida la canalización integrada de ASP.NET. Esto ofrece una opción muy cómoda para mejorar los marcos de aplicaciones con servicios ASP.NET sin convertirlos a ASP.NET. Y también permite que colaboren las aplicaciones que usan distintos marcos. Para ver un ejemplo de cómo se puede usar para mejorar las aplicaciones existentes con funcionalidad y mejorar el rendimiento sin cambiar el código, consulte mi artículo de MSDN® Magazine "Mejora de las aplicaciones con la canalización integrada de ASP.NET" (disponible en msdn.microsoft.com/magazine/cc135973.aspx).
Aumento de la densidad de aplicaciones
IIS 7.0 incluye muchas mejoras diseñadas para aumentar la densidad de las aplicaciones que se pueden hospedar en un solo servidor. Estas mejoras forman parte de numerosas características que proporciona IIS 7.0 para mejorar la calidad del hospedaje compartido, lo que incluye un aprovisionamiento de sitio mejorado y un mejor aislamiento de aplicaciones.
Desde el punto de vista del rendimiento, las mejoras se centran principalmente en dos aspectos del aumento de la densidad de aplicaciones: aumentar el número de aplicaciones que se pueden aprovisionar en un servidor IIS 7.0 y aumentar el número de aplicaciones que pueden estar activas en un momento determinado.
Tenga en cuenta que IIS 7.0 permite aprovisionar un número mayor de aplicaciones en cada servidor de lo que antes era posible; en algunas pruebas internas, fue posible hospedar hasta 100.000 sitios en un solo servidor. Esto se basa en la capacidad de crear y configurar un gran número de sitios y aplicaciones.
Pero cuidado, para conseguir el aprovisionamiento a alta velocidad, se debe cambiar a las nuevas API de configuración, ya que con las anteriores no se puede lograr. Además, no todas las API de configuración de IIS proporcionan las mismas características de rendimiento, por lo que se debe realizar una selección cuidadosa para garantizar un alto rendimiento. Si tiene dudas, busque las opciones de configuración que aprovechen los nuevos objetos de configuración de IIS directamente, incluido el espacio de nombres Microsoft.Web.Administration, la herramienta de la línea de comandos AppCmd.exe y los objetos de configuración COM de IIS, a los que se obtiene acceso desde script, .NET o código C++.
La diferencia entre cuántos sitios se pueden aprovisionar y cuántos pueden estar activos es una distinción muy importante en la arquitectura de IIS, que usa aplicaciones persistentes y procesos de trabajo para efectuar el procesamiento de solicitudes. En este modelo, las aplicaciones activas consumen más recursos en el servidor, pero también proporcionan mejor rendimiento sostenido debido al almacenamiento en caché y los costos de inicialización eliminados.
Debido a que cada aplicación activa requiere una determinada cantidad de memoria y un proceso de trabajo independiente (si se usa el modelo de aislamiento de aplicaciones recomendado), el número de aplicaciones activas depende del tamaño de memoria de aplicación. Por lo tanto, aunque una única aplicación que sólo sirve contenido estático puede requerir no más de 3 MB para su proceso de trabajo (e incluso puede compartirlo con otras aplicaciones de contenido estático), algunas aplicaciones dinámicas pueden requerir 100 MB o más de RAM incluso cuando se hace un uso bajo. Esto convierte la sobrecarga de memoria del proceso de trabajo de IIS en insignificante cuando se compara con el tamaño de la aplicación al definir la máxima densidad posible.
En el escenario típico de hospedaje compartido es habitual ver lo que se denomina la distribución 80/20, donde el 80% de las solicitudes va al 20% de los sitios. Esto tiene como resultado un porcentaje pequeño de los sitios que están activos en un momento determinado. Para permitir un mayor número de sitios activos, IIS 7.0 proporciona administración del ciclo de vida activa. Esto puede ayudarle a recuperar memoria de las aplicaciones inactivas con el fin de permitir el hospedaje de más aplicaciones activas.
IIS 7.0 presenta un nuevo algoritmo, denominado tiempo de espera dinámico, que ajusta de forma proactiva los tiempos de espera de inactividad de los procesos de trabajo según la memoria disponible en el servidor. A medida que se reduce la memoria, las aplicaciones inactivas se quitan más rápidamente, lo que permite que se hospeden más aplicaciones activas. No obstante, si hay memoria disponible, los tiempos de espera pueden ser grandes para proporcionar mejor rendimiento y mantener el estado de la aplicación. Además de permitir que más aplicaciones estén activas, el tiempo de espera dinámico también contribuye a evitar las situaciones de memoria que provoquen un deterioro grave del rendimiento debido a la hiperpaginación.
Para poder hospedar muchas aplicaciones activas, también se debe sacar provecho de un sistema operativo de 64 bits, ya que se permitirá que el sistema operativo direccione más de 4 GB de memoria. A partir de esto se pueden configurar los procesos de trabajo de IIS para que se ejecuten en modo de 32 bits (SysWoW64), donde consumen menos memoria, a la vez que permiten que el sistema operativo direccione más memoria de la que sería posible en un entorno de 32 bits.
Reducción de ancho de banda mediante compresión
No es de sorprender que los costos de ancho de banda constituyan los principales en un centro de datos orientado a Internet. Además, el ancho de banda necesario para proporcionar el contenido solicitado es un factor clave en la capacidad de respuesta percibida de la aplicación.
Una de las formas más efectivas de reducir el ancho de banda necesario para proporcionar las respuestas de aplicación es el uso de la compresión HTTP. Esto puede reducir de forma considerable el tamaño de la respuesta, normalmente hasta una décima parte cuando se aplica a contenido de texto de fácil compresión, como HTML. Lo mejor de todo es que prácticamente todos los exploradores de escritorio lo admiten y los costos de descompresión en el hardware de escritorio son menores si se comparan con el ahorro de latencia derivado del envío de menos datos. Y como la compresión se basa en la negociación de codificación de contenido definida en el protocolo HTTP 1.1, su habilitación es segura para los clientes que no admiten compresión, ya que estos clientes simplemente reciben una versión sin comprimir del contenido.
IIS 7.0 ofrece las dos características de compresión presentadas por su antecesor: compresión estática y compresión dinámica. Con la compresión estática se comprime previamente el contenido estático y se guarda en disco, lo que permite servir contenido comprimido directamente a las solicitudes futuras sin la sobrecarga de la compresión. Con la compresión dinámica se comprime la respuesta en tiempo real y, por lo tanto, se habilita la compresión de las respuestas generadas por las aplicaciones. Cualquier marco de aplicaciones en IIS 7.0 puede aprovechar la compresión dinámica, incluido ASP, ASP.NET o PHP.
A pesar de la creencia común, la compresión dinámica normalmente no tiene una sobrecarga de CPU prohibitiva. De hecho, la compresión dinámica suele suponer menos del 5% del uso de CPU total en un servidor ocupado. La compresión dinámica se puede implementar de un modo libre para permitir un ahorro de ancho de banda máximo para cualquier carga de trabajo de aplicación.
Se puede optimizar la sobrecarga de compresión si se configura el nivel de compresión de modo que se logre la compresión deseada según la relación de sobrecarga de CPU. Pero eso no es todo, también se puede configurar la aplicación para habilitar el almacenamiento en caché del contenido comprimido, lo que elimina la sobrecarga de compresión en aciertos de caché al servir contenido ya comprimido. Tenga en cuenta que las cachés de ASP.NET y de resultados de IIS se han actualizado con la capacidad opcional de almacenar en caché el contenido comprimido para los clientes que lo admitan, así como el tratamiento de las solicitudes de clientes que requieran contenido sin comprimir.
Limitación de velocidad de bits de medios
Con el aumento de sitios que ofrecen contenido multimedia, los costos de ancho de banda para muchas compañías están subiendo vertiginosamente. Y lo que es peor, un gran porcentaje del ancho de banda de medios se desperdicia porque el contenido multimedia enviado al cliente nunca se usa realmente. ¿Por qué sucede esto?
Piense en la última vez que vio un vídeo en línea o vio un anuncio de vídeo mientras exploraba. ¿Vio el vídeo hasta el final? Es habitual que los usuarios que exploran sitios de vídeos vean únicamente una parte de un vídeo antes de pasar al siguiente o salir de la página. No obstante, un servidor web que use descarga progresiva para entregar el vídeo normalmente enviará muchos más datos de los necesarios para esos pocos segundos de reproducción. La mayor parte de los datos nunca se usa.
Si los vídeos, de media, sólo se ven durante 5 segundos pero se suministran (en búfer) 30 segundos de datos de vídeo en esos 5 segundos, se está perdiendo potencialmente más del 80% del ancho de banda.
Hace uno año, para resolver este problema para un cliente que estaba adoptando una versión beta de IIS 7.0, escribí un módulo de limitación de ancho de banda que detectaba automáticamente la velocidad de bits de vídeo y garantizaba que el servidor entregaba el vídeo al cliente prácticamente a la misma velocidad. El equipo de medios de IIS seleccionó este módulo, que se denomina módulo de limitación de velocidad de bits (consulte la figura 4) y está disponible en el centro de descarga de iis.net (iis.net/downloads/?tabid=34&g=6&i=1640). Puede obtener más información acerca de él en el blog de Scott Guthrie (disponible en go.microsoft.com/fwlink/?LinkId=122514).
Figura 4 La limitación de la limitación de velocidad de bits minimiza el uso de ancho de banda (haga clic en la imagen para ampliarla)
El módulo de limitación de velocidad de bits detecta automáticamente la velocidad de codificación de los tipos de vídeo más conocidos. Se puede controlar la cantidad de datos que se desea enviar previamente al cliente con el fin de eliminar los retrasos de búfer iniciales (inicio rápido) y el porcentaje de la velocidad codificada a la que se desea entregar el contenido. También puede configurar otras numerosas opciones, como el ancho de banda máximo y las conexiones simultáneas, así como controlar el módulo mediante programa.
Almacenamiento en caché de los resultados
Por lo general, el almacenamiento en caché es la principal manera de mejorar el rendimiento de las aplicaciones que ejecutan trabajo repetido. A diferencia de las mejoras de rendimiento específicas de la aplicación, que normalmente requieren muchos esfuerzos y quitar la sobrecarga de procesamiento de una aplicación, el almacenamiento en caché elimina la sobrecarga de las solicitudes repetidas para el mismo contenido.
Antes de IIS 7.0, tanto IIS como ASP.NET habían ofrecido capacidades de almacenamiento en caché en forma de caché de kernel de IIS y la caché de resultados de ASP.NET. La caché de kernel de IIS proporcionaba el máximo rendimiento, pero estaba restringida principalmente al contenido estático. La caché de resultados de ASP.NET era con diferencia la solución más completa para almacenar en caché el contenido dinámico, aunque con un rendimiento más lento y una administración de memoria menos eficaz. La nueva caché de resultados de IIS 7.0 llena el vacío entre la caché de kernel de IIS y la caché de resultados de ASP.NET.
La caché de resultados de IIS 7.0 permite el almacenamiento en caché de contenido dinámico de cualquier aplicación, incluido ASP, ASP.NET, PHP y cualquier marco de aplicaciones compatible con IIS 7.0. Al proporcionar compatibilidad básica para la variabilidad y caducidad de contenido, esta nueva característica permite implementar el almacenamiento en caché para el contenido que la caché del kernel de IIS no puede almacenar. Sin embargo, permite el uso de la caché del kernel para contenido que cumple las restricciones.
Además, la caché de resultados de IIS 7.0 también proporciona una alternativa de mayor rendimiento a la caché de resultados de ASP.NET para el contenido ASP.NET que no requiere las características avanzadas de almacenamiento en caché (como las dependencias de caché o la invalidación) que sólo están disponibles en la caché de resultados de ASP.NET.
En lo que se refiere al almacenamiento en caché de los resultados, los desafíos normalmente se encuentran en la definición de las directivas de caducidad, invalidación y variabilidad de contenido adecuadas que permitan el almacenamiento en caché de respuestas eficaz a la vez que se mantienen la corrección y actualización de la caché necesarias. La mayoría de las veces, esta operación se puede realizar simplemente con la configuración de las reglas de almacenamiento en caché correctas, aunque algunas situaciones requieren directivas más complejas que dependen de la información en tiempo de ejecución. Para ocuparse de esto, la caché de resultados de IIS 7.0 proporciona unas API de programación que se pueden usar para garantizar el comportamiento de almacenamiento en caché adecuado. De este modo se libera el potencial de rendimiento de almacenamiento en caché para el contenido que, de otro modo, no se beneficiaría de dicho almacenamiento. Además, la canalización integrada de ASP.NET permite el uso de la caché de resultados de ASP.NET para contenido que no es de ASP.NET.
La implementación de la caché de resultados para el contenido dinámico puede resultar compleja y requerir una estrategia multinivel para capitalizar las eficacias y la flexibilidad de las diferentes características de almacenamiento en caché de la plataforma IIS 7.0. Esto suele incluir la descripción de múltiples parámetros que afectan a la respuesta y la definición de las estrategias de caducidad e invalidación para mantener la actualización de la caché y, a continuación, determinar la caché que admitirá la semántica necesaria.
Pero casi siempre esta complejidad merece la pena. Al implementar la caché de resultados de IIS 7.0, se pueden obtener mejoras de varios órdenes de magnitud en el rendimiento global de la aplicación y la reducción correspondiente de la carga en los componentes de nivel de base de datos y empresarial.
Conversión del código ISAPI en módulos de IIS 7.0
IIS 7.0 presenta una nueva API de servidor en la que se basan todos los módulos de IIS 7.0. Reemplaza las API de filtro y extensión de ISAPI que se usaban en las versiones anteriores de IIS. Para los nuevos módulos que no necesitan admitir versiones anteriores, las nuevas API son más fáciles de usar, ayudan a producir código de servidor más confiable y son mucho más eficaces.
No obstante, IIS 7.0 proporciona una opción para admitir los filtros y extensiones de ISAPI existentes mediante una capa de compatibilidad implementada a través de módulos de IIS 7.0 opcionales. Esto permite que los componentes de ISAPI existentes funcionen en IIS 7.0 sin que se deban reescribir.
Aunque el uso de las inversiones en ISAPI existentes baja el listón para la migración a IIS 7.0, debe considerar seriamente la posibilidad de migrar el código ISAPI anterior a las nuevas API de IIS 7.0. Si se hace así, se elimina la sobrecarga de la capa de compatibilidad con ISAPI y se liberan las ventajas de rendimiento que no están disponibles para los componentes de ISAPI. En función del trabajo que desarrolle el componente de ISAPI, estas ventajas de rendimiento pueden ser bastante considerables. Por ejemplo, la API de módulos de IIS 7.0 proporciona compatibilidad integrada para almacenar en caché metadatos de configuración y otros datos arbitrarios asociados a sitios, aplicaciones y direcciones URL que pueden acelerar considerablemente las operaciones internas del componente.
Además, la API de módulos de IIS permite que los módulos realicen operaciones de larga ejecución asincrónicamente, como la recepción de datos de entidad de solicitud o el envío de respuesta. La realización de estas tareas asincrónicamente permite que el servidor se escale a una gran cantidad de clientes simultáneos (decenas de miles), en vez de ampliarse a decenas o, como mucho, centenares de clientes simultáneos debido a las limitaciones en el número de subprocesos de solicitud. El procesamiento asincrónico también puede eliminar el efecto de procesamiento en otras solicitudes y actividades de la aplicación, reducir el uso de la memoria y habilitar una utilización de CPU mucho mejor.
A partir de los patrones específicos que afectan al rendimiento, la API nativa ofrece a los desarrolladores mayor flexibilidad para las tareas de procesamiento de solicitudes. Esto le permitirá mejorar el diseño del componente de servidor y, a su vez, obtener mayor eficacia. Por ejemplo, determinadas tareas de filtrado que anteriormente requerían extensiones de ISAPI de comodín y ejecución de solicitudes secundarias ahora se pueden llevar a cabo en un módulo durante la solicitud original y también pueden permitir el almacenamiento en caché del kernel de IIS para la respuesta.
Esto puede requerir el desarrollo de prototipos y experimentación para determinar el diseño óptimo que maximice las ventajas de la migración. Debido a las diferencias de arquitectura fundamentales entre ISAPI y la API de módulos de IIS 7.0, la vía de migración directa no es necesariamente la adecuada. La buena noticia es que la API de módulos de IIS 7.0 también es más sencilla de usar que ISAPI, por lo que la migración resulta menos difícil.
Extensibilidad de servidor
IIS 7.0 ofrece extensibilidad de un extremo a otro. Se requiere un buen conocimiento previo del funcionamiento del servidor, pero también se libera un potencial enorme para ganancias de rendimiento específico de la aplicación. Con el conocimiento de la arquitectura de servidor y el procesamiento de solicitudes, puede aprovechar esta extensibilidad para diseñar soluciones de rendimiento personalizadas y adaptadas a sus requisitos de aplicación, carga de trabajo y hardware.
Se puede presentar como el reemplazo de cualquiera de las características de IIS 7.0 integradas con implementaciones personalizadas. Aunque se han realizado numerosas pruebas de optimización y rendimiento de las características de IIS 7.0, evidentemente no se han optimizado para todos los usos posibles. Por lo tanto, puede poder mejorar el rendimiento de módulos específicos si crea optimizaciones para su carga de trabajo específica. Por ejemplo, puede decidir volver a implementar el módulo de listado de directorio para almacenar en memoria los listados de directorio en vez de usar las API del sistema de archivos para enumerar archivos.
La extensibilidad también se puede usar para crear nuevas características de rendimiento. Los ejemplos integrados de estas características son la caché de resultados, los módulos de compresión y otras cachés internas.
Para determinar la necesidad de una característica de rendimiento personalizada debe comprender las características de rendimiento de su aplicación y su carga de trabajo, así como conocer el cuello de botella que debe solucionar. IIS 7.0 proporciona compatibilidad de diagnóstico amplia para el análisis del rendimiento, lo que facilita la comprensión de los requisitos y el diseño posible de las características que necesita.
Conclusión
Aunque la versión IIS 7.0 es principalmente una versión funcional, ofrece mejoras de rendimiento considerables derivadas de su arquitectura modular, capacidad de configuración y nuevas características de rendimiento. Estas mejoras pueden preparar el terreno para un ahorro empresarial importante mediante la consolidación de servidores y la reducción de costos de ancho de banda, así como proporcionar una mejor experiencia del usuario.
Para aprovechar correctamente muchas de estas mejoras, normalmente es necesario realizar un análisis exhaustivo de la plataforma de aplicaciones actual y conocer a fondo la arquitectura de IIS 7.0. Para obtener más información acerca de la arquitectura de IIS 7.0 y las características mencionadas en este artículo, visite iis.net. En el blog de mvolo.com ofreceré más información acerca de técnicas que aprovechan de forma proactiva IIS 7.0 para mejorar el rendimiento de las aplicaciones y reducir los costos operativos.
Mike Volodarsky es un antiguo director de programas del equipo IIS de Microsoft. Durante los últimos cinco años ha impulsado el diseño y desarrollo del conjunto de características básicas de ASP.NET 2.0 e IIS 7.0. Ahora crea tecnologías de servidor web avanzadas para granjas de servidores web de alto rendimiento que usan IIS 7.0 y Windows Server 2008. Mike es el autor principal del libro IIS 7.0 Resource Kit y escribe para MSDN Magazine y su blog de IIS 7.0, mvolo.com.