[Mongrel] Design flaw? - num_processors, accept/close
paul at paulbutcher.com
Tue Oct 16 09:01:16 EDT 2007
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.
Snetterton, Castle Combe, Cadwell Park...
Who says I have a one track mind?
MSN: paul at paulbutcher.com
More information about the Mongrel-users