[Mono-dev] Architectural decisions behind mod_mono
jay-MonoDev at toaster.com
Mon Mar 9 12:59:53 EDT 2009
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.
More information about the Mono-devel-list