[Mono-dev] Architectural decisions behind mod_mono

[Jay Logue]

I'm going to have to disagree with Rodrigo here.  For "MySpace/Facebook 
level web applications" (the op's hypothetical target) the reliability 
issue is a bit of a red herring.  In these environments applications are 
frequently segregated onto their own machines for operational reasons.  
Thus, if an app has crapped out on a machine, the whole machine is 
useless.  It doesn't matter that the web server is still up and 
responding to requests (presumably with 500 errors).  In these 
situations, application isolation takes a backseat to performance. 

Unfortunately Microsoft has a long history of confusion on this topic.  
I remember back when IIS5 was being developed I implored the IIS team 
make it possible to write filters as kernel modules.  I insisted that 
the extra kernel transitions needed to invoke my legacy encryption 
filter was going to kill performance.  Their reaction was 'No way! You 
might blue-screen the machine!'.  They never did understand that, 
whether it was in user space or the kernel, if there was a fatal bug in 
my filter the machine was no more useful than a doorstop. 
> This is a minor issue that should pose no scalability issues on itself.
There's no question that the number of process boundary transitions per 
request has a significant impact on performance.  If that weren't the 
case we'd all be running microkernels and IIS would never have been 
pushed into the OS.  That said, I will agree that this is rarely the 
dominant performance issue.  Usually the application's (mis-)behavior 
swamps that of the infrastructure.  Still, it would be nice to have a 
high-performance, cross platform ASP.NET hosting environment that could 
wring the most out of what ever OS it was running on.

-- Jay