Comparación de mapas comodín IIS 6.0?

Question

Me estoy enamorando rápidamente de ASP.NET MVC beta, y una de las cosas que he decidido no sacrificar al implementar en mi entorno de alojamiento IIS 6 es la URL sin extensión. Por lo tanto, estoy considerando la posibilidad de agregar un mapeo comodín, pero todo lo que leo sugiere un posible impacto en el rendimiento cuando se usa este método. Sin embargo, no puedo encontrar ningún punto de referencia real.

La primera parte de esta pregunta es, ¿sabe dónde podría encontrar tales puntos de referencia, o es solo una suposición no probada?

La segunda parte de la pregunta se refiere a las 2 pruebas de carga que ejecuté utilizando jMeter en nuestro servidor de desarrollo a través de una conexión de 100Mbs.

Información de Antecedentes

Nuestro proveedor de alojamiento tiene un tubo de internet rompible 4gbs con una espina dorsal 1Gbs para nuestra VLAN, así que cualquier cosa que pueda producir más de la LAN de la oficina debe traducir bien al entorno de alojamiento.

El escenario de prueba consistía en cargar varias imágenes/archivos css, ya que el supuesto golpe de rendimiento se produce al solicitar archivos que ahora se pasan a través del filtro ISAPI de ASP.NET que normalmente no pasaría por él. Cada prueba contenía 50 hilos (usuarios simulados) que ejecutaban el script de solicitud de 1000 iteraciones cada uno. Los resultados de cada prueba se publican a continuación.

Resultados de la Prueba

Sin asignación de comodín:

 
Samples: 50,000 
Average response time: 428ms 
Number of errors: 0 
Requests per second: 110.1 
Kilobytes per second: 11,543 

Con asignación de comodín:

 
Samples: 50,000 
Average response time: 429ms 
Number of errors: 0 
Requests per second: 109.9 
Kilobytes per second: 11,534 

Ambos ensayos se realizaron caliente (todo estaba en la memoria, no sesgo de carga inicial) y, desde mi punto de vista, el rendimiento fue aproximadamente par. El uso de CPU fue aproximadamente del 60% durante la duración de ambas pruebas, la memoria estaba bien y la utilización de la red se mantuvo constante en torno al 90-95%.

¿Es esto una prueba suficiente de que las asignaciones de comodines que pasan por el filtro ASP.NET para TODO el contenido no realmente afectan el rendimiento, o me falta algo?

Edit: 11 horas y no hay un comentario? Esperaba más ... lol

Answer 1

Chris, publicación muy útil.

Muchos de los que sugieren una desventaja de rendimiento infieren que el código procesado en una aplicación web es de alguna manera diferente/inferior al código procesado en el flujo de trabajo estándar. El tipo de código base puede ser diferente, y seguro que necesitarás el intérprete MSIL, pero MS ha demostrado que en muchos casos verás un aumento en el rendimiento en un tiempo de ejecución .NET sobre uno nativo.

También es conveniente tener en cuenta la forma de IIS tiene que ser un "aprendiz de todo" - que permite todo tipo de configuración y anula incluso en archivos estáticos. Algunos de ellos están diseñados para aumentar el rendimiento (almacenamiento en caché, compresión) y, de hecho, se perderán a menos que los vuelva a implementar en su código, pero muchos de ellos son para otros fines y es posible que nunca se utilicen. Si compila para sus necesidades (solo), puede ignorar esas otras piezas y debería obtener algún tipo de ventaja de rendimiento, aunque exista una desventaja potencial de ASP.NET.

En mi (no- .NET) prueba de MVC estoy viendo beneficios de rendimiento considerables (10x o más) sobre las formas web. Incluso si hubiera un pequeño golpe en el contenido estático, no sería una píldora difícil de tragar.

No me sorprende que la diferencia sea casi insignificante en sus pruebas, pero me complace ver que se haya respaldado.

NOTA: Puede deshabilitar la asignación de comodines desde los directorios estáticos (guardo todos los archivos estáticos en/static/(pics | styles | ...)) en IIS. Cambie la carpeta a una aplicación, elimine la asignación de caracteres comodín y cámbiela de una aplicación y - voilà - los archivos estáticos son manejados por IIS sin molestar a su ASP.NET.

Answer 2

Estaba buscando un punto de referencia como este durante mucho tiempo. Gracias!

En mi empresa hicimos mapeo de comodines en varios sitios web (formularios web estándar, .net1.1 y 2, iis6), y los administradores de sistemas me dijeron que no notaron ningún problema de rendimiento.

Pero, parece que estresado red, no servidor. Entonces, ¿tal vez los puntajes son tan similares porque el cuello de botella de la red? Sólo de pensar ...

Answer 3

creo que hay varias cosas adicionales para comprobar:

• Puesto que estamos utilizando el filtro ISAPI .Net, podríamos estar usando hilos utilizados para ejecutar la aplicación para servir activos estáticos.Ejecutaría la misma prueba de carga mientras revisaba contadores de rendimiento de subprocesos: Review this link
• Ejecutaría la misma prueba de carga mientras ejecutaba Microsoft Performance Analyzer y comparaba los informes.

Answer 4

Esa es una publicación bastante impresionante, muchas gracias por eso.

También estamos evaluando las preocupaciones de seguridad y rendimiento con la eliminación de un software que siempre ha estado disponible para filtrar el tráfico no deseado.

¿Habrá alguna otra evaluación comparativa de su parte?

Cheers,

Karl.

Answer 5

Parece que el cuello de botella en su prueba es la utilización de la red. Si se espera que la degradación del rendimiento esté en el uso de la CPU (no estoy seguro de que sea así, pero es razonable), entonces no lo notarías con la prueba que hiciste.

Dado que este es un sistema complejo, con muchas variables, no significa que no haya degradación del rendimiento. Significa que en su escenario, la degradación del rendimiento es probablemente insignificante.