[Mongrel] Design flaw? - num_processors, accept/close

[Paul Butcher]

On 16 Oct 2007, at 13:45, Zed A. Shaw wrote:
> No, as usual performance panic has set in and you're not looking at  
> the problem in the best way to solve it.

Sorry Zed, I have a great deal of respect for your work and your  
opinions on development. But you seem to have a blind spot here and I  
just don't understand why.

This has nothing to do with optimisation. It has nothing to do with  
performance. It's got everything to do with resilience and reliability.

Clearly what you say about waiting for remote services is true. Doing  
so is a Bad Thing and an application shouldn't do it. But you're  
missing the point.

Your philosophy guarantees that your applications performance will be  
held hostage by the worst performing action within it. What if I  
screw up and accidentally roll out "bad" action. Should this mean  
that *every aspect* of my app now behaves terribly? Following your  
logic, it does. The whole point of a load balancer is that it should  
enable things to behave sensibly even if one of my backend servers is  
screwed up. But a mismatch between the expectations encoded within  
mod_proxy_balancer and Mongrel running Ruby on Rails means that this  
isn't the case.

Similarly, if I write a quick and dirty reporting action which runs  
an SQL query which takes 10 seconds to complete, should that screw up  
my entire application? It seems unreasonable to me that I have to  
optimise an action like this (why should I care if a reporting action  
which is only used once a day takes 10 seconds to complete?). I *do*  
care if every time I run it, though, I cause all the 0.1 second  
actions to queue up behind it.

--
paul.butcher->msgCount++

Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?

http://www.paulbutcher.com/
LinkedIn: https://www.linkedin.com/in/paulbutcher
MSN: paul at paulbutcher.com
AIM: paulrabutcher
Skype: paulrabutcher