So, in a nutshell what all this is telling me so far, is, that there is no way to bypass the pipeline's Http Modules (which seems to be a general ASP.NET issue rather than something specific to DNN, right ?). So the discussion is left with the question about what the Http Modules shall be:
Of course there are many good reasons why the Http Modules are the way they are - as long as you have the DNN application scenario's in mind, DNN originally has been architected for - Portals and Modules.
But there are also other scenarios that do not fit into this pattern: For instance take the DNN's own KeepAlive.aspx which, although it just returns the system time, still goes through all the HttpModules' overhead !
In my case, all my client application requests will be channeld through a single, portal, module and user independent Gateway, that again might or might not route all the traffic forward to the DNN business objects in charge.
In this setup, some of the requests will just "poll" the Gateway's own status (similar to KeepAlive.aspx) - and therefore has absolutely nothing to do with DNN and does not need ANY of the HttpModule's functionality.
Anyway, DNN is a great system and maybe my concerns have just risen, because I am trying to extend DNN into a direction it was never ment to be. DNN's whole architecture is based on Portals and Modules and this is a great thing for most of us.
On the other hand, I am currently not clear, about the concept for extending DNN on APPLICATION level (in my case, having a different entry-point than default.aspx).
So my final conlusion here so far is: The current Http Modules' view is "Portal/Module" only and currently do not allow a more generic host-level approach that runs beside rather than "on top" of the current Portal/Module paradigm.
right ?
hmm - seems that my concerns have become some sort of academic and maybe, now that I have got the confirmation that DNN ist what it is, it is time to go back to code again.
Thank you all for your help - was very insightfull
kind regards
Rene
P.S.
to keep the discussion somehow focused on the PIPELINE:
I absolutely agree, that the pipline issues is NOT the major performance threat - but the issue I want to discuss, is not performance in GENERAL, but the PIPELINE's role and performance impact for the scenario's mentioned above.