[Mono-dev] Architectural decisions behind mod_mono
jay-MonoDev at toaster.com
Mon Mar 9 22:47:58 EDT 2009
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list