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

[Paul Butcher]

On 16 Oct 2007, at 06:49, Zed A. Shaw wrote:
> On Mon, 15 Oct 2007 16:43:34 -0700
> "Brian Williams" <bwillenator at gmail.com> wrote:
>
>> We recently ran into exactly this issue.  Some rails requests were  
>> making
>> external requests that were taking 5 minutes (networking issues  
>> out of our
>> control).
>
> Now that's a design flaw.  If you're expecting the UI user to wait  
> for a backend request that takes 5 minutes then you need to  
> redesign the workflow and interface.  Do it like asynchronous email  
> where the use "sends a request", "awaits a reply", "reads the  
> reply", and doesn't deal with the backend processing chain of events.

Zed, you're being obtuse. Of course that isn't what Brian means. What  
he's doing is giving a pathological example to illustrate just how  
badly the mod_proxy_balancer/mongrel/rails combination behaves when  
things go wrong.

Yes, you can mask the problem to some extent by mucking about with  
your application (and in fact that's what we've done here), but  
that's missing the point.

It is not unreasonable to expect that some actions performed by an  
application are "fast" and some are "slow". It's further not  
unreasonable to expect a very large difference between the fastest  
and the slowest actions (if one action takes 10ms and another takes  
1s, that's not unreasonable - but it is a 2 order of magnitude  
difference).

With the obvious setup, fast actions will be delayed behind slow  
actions. This is a Bad Thing.

Furthermore, people are fallible. If I happen to accidentally  
introduce an action into my system which takes 10s, yes I've screwed  
up and should fix it. But is it reasonable for the fact that I have a  
single (possibly very rare) action which takes 10s to mean that all  
the other fast actions are affected? Even when most of my mongrels  
are idle?

Of course, this isn't really a problem with Mongrel. It's a problem  
with Ruby (which doesn't know what the word "thread" means) and Rails  
(which doesn't even manage to successfully make use of the brain-dead  
version of threading which Ruby does support).

--
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