[Mono-dev] Architectural decisions behind mod_mono

[Jay Logue]

Alan McGovern wrote:
>
>     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.
>
>
> So if there's a bug in your filter which caused every 100th request to 
> bluescreen the computer, yes you're right. Your computer would be no 
> more useful than a doorstop. But if every 100th request just crashed 
> the process, you could just restart the process and continue fine for 
> the next 99 requests. Which solution is better? Does performance even 
> come into the equation here?

At the loads I'm talking about a failure every 100th request occurs at 
least once a second per server if not faster.  Even if I only loose the 
application process, if all the servers in my 300 server network are 
failing once a second, I've got a big problem.  (At a minimum imagine 
the reconnect storm to the back-end servers if the web servers loose 
their connection pools once a second).

Still, its valid to say that at some intermediate failure rate, process 
failures would be preferable to blue screens.  However the decision 
ultimately comes down to a trade off between the cost to QA the software 
to an acceptable failure rate verses the cost of adding and maintaining 
more machines.  And my point to the IIS people was that I should be the 
one to make that decision, not them.

In a similar vein I think it would be useful to have a high-performance 
ASP.NET hosting app that avoids the need for multiple process boundary 
transitions.   Note that I'm not saying that this is a priority for the 
mono development effort, or even that the mono team should develop such 
a thing, just that it would make sense from a cost-benefit standpoint in 
some circumstances.

-- Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090309/c843035c/attachment.html