IIS7 Integrated vs Classic Pipeline: ¿qué utiliza más subprocesos ASP.NET?

Question

Con canalización integrada, todas las solicitudes se pasan a través de ASP.NET, incluidas imágenes, CSS.

Mientras que, en la canalización clásica, solo las solicitudes de páginas ASPX se pasan por defecto a través de ASP.NET.

¿Podría la tubería integrada afectar negativamente el uso de la rosca?

Supongamos que petición de archivo de 500 MB binario desde un servidor IIS:

• con la tubería integrada, un subproceso de trabajo ASP.NET sería utilizado para la descarga binario (¿verdad?).
• Con canalización clásica, la solicitud es servida directamente por IIS, por lo que no se utiliza ningún subproceso ASP.NET .

Para mí, esto favorece la tubería clásica, ya que me gustaría el mayor número de subprocesos para servir páginas ASPX.

¿Estoy completamente fuera de base aquí?

Answer 1

Si mira machine.config, web.config y applicationHost.config en IIS 7, puede ver que la forma en que se sirve el contenido estático no cambia cuando cambia entre la canalización clásica y la integrada. Lo único que cambia es si las solicitudes asignadas a asp.net pasan a través de un módulo administrado o el módulo de filtro ISAPI nativo.

Lo único que podría afectar el rendimiento es si modifica las configuraciones predeterminadas para los módulos de autorización y cualquier módulo personalizado que haya agregado para ejecutar al manejar solicitudes de contenido estático. E incluso aquí, la sobrecarga es probablemente insignificante.

Por lo tanto, un punto de referencia más apropiado sería IIS 6 vs IIS 7, y sospecho que IIS 7 sería el claro ganador.

Answer 2

Yo diría que tienes razón, pero lo veo desde otra perspectiva.

¿Necesita procesar las solicitudes para las páginas que no son ASPX? Por ejemplo, para iniciar sesión o para prohibir la respuesta si no se cumple alguna condición.

Si necesita esta capacidad de procesamiento, use la tubería integrada. Si no lo hace, use la tubería clásica.