views:

806

answers:

3

With integrated pipeline, all requests are passed through ASP.NET, including images, CSS.

Whereas, in classic pipeline, only requests for ASPX pages are by default passed through ASP.NET.

Could integrated pipeline negatively affect thread usage?

Suppose I request 500 MB binary file from an IIS server:

  • With integrated pipeline, an ASP.NET worker thread would be used for the binary download (right?).
  • With classic pipeline, the request is served directly by IIS, so no ASP.NET thread is used.

To me, this favors classic pipeline, as I would like as many threads as possible to serve ASPX pages.

Am I completely off base here?

A: 

I'd say you're right, but I' look at it from another perspective.

Do you need to process the requests for the non-ASPX pages ? For example, to log them, or to forbid the response if some condition is not met.

If you need this processing capability, use integrated pipeline. If you don't, use the classic pipeline.

Timores
I need to serve static content: CSS, JS, JPG, PNG, etc. These (especially images) account for a greater percentage of bandwidth than the ASPX page content.
frankadelic
But do you need any processing by .NET code for this static content ?
Timores
No, but my assumption here is that using integrated pipeline will cause static content to be delivered by ASP.NET, rather than directly by IIS.
frankadelic
This is the way I understand it, too, and what I was trying to explain in the answer :-) Use classic pipeline mode.
Timores
+3  A: 

If you look at machine.config, web.config and applicationHost.config in IIS 7, you can see that the way static content is served does not change when you switch between classic and integrated pipeline. The only thing that changes is whether requests mapped to asp.net pass through a managed module or the native ISAPI filter module.

The only thing that could affect performance is if you modify the default settings for authorization modules and any custom modules you've added to execute when handling requests for static content. And even here the overhead is probably negligible.

Therefore a more appropriate benchmark would be IIS 6 vs IIS 7, and I suspect IIS 7 would be the clear winner.

Chris Eldredge
A: 

Try this... http://learn.iis.net/page.aspx/244/how-to-take-advantage-of-the-iis7-integrated-pipeline/

This should answer a few of your questions.

Rahul Soni