integrado - IIS7 Integrated vs Classic Pipeline-¿Qué utiliza más subprocesos ASP.NET?

iis modo integrado

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 interconexión integrada afectar negativamente el uso de subprocesos?

Supongamos que solicito un archivo binario de 500 MB de un servidor IIS:

• Con la canalización integrada, se usaría un hilo de trabajo ASP.NET para la descarga binaria (¿verdad?).
• Con la canalización clásica, IIS envía directamente la solicitud, por lo que no se utiliza subproceso de ASP.NET.

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

¿Estoy completamente fuera de la base aquí?

Answer 1

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

¿Necesita procesar las solicitudes de 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 una tubería integrada. Si no lo hace, use la tubería clásica.

Answer 2

Si observa 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 la configuración predeterminada 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.