[Mongrel] Shared listening sockets

Steve Midgley public at misuse.org
Wed Oct 24 11:04:51 EDT 2007


On 10/23/07, Robert Mela <rob at robmela.com> wrote:
 > Several years back I accidentally discovered that multiple processes 
can
 > listen on the same TCP/IP socket.  The trick of course is that all 
the
 > processes are in the same process group, and the socket is opened by 
a
 > shared parent.   The OS somehow was managing queuing up the various
 > calls to accept() on that socket.   Since the watchdog parent / 
multiple
 > child servers is a common, this was a workable solution on the 
versions
 > of Linux we were using.
[snip]
At 05:09 AM 10/24/2007, Wayne wrote:
>I believe that the main issue here is on the win32 platform, Luis?
>
>We do have something similar in the works for a future release, 
>however I am
>unsure as to how your suggestion ties in at the moment. It appears to 
>be
>well worth investigation for what we have planned.
>
>Thank you kindly for this,
>
>   ~Wayne

Hi,

I thought I'd chime in as a Windows developer. I'm running Windows in 
development mode and deploying to Linux (Ezra's rig at EngineYard 
actually).

If this idea actually works, it's super appealing for me as a simple 
solution to the "slow returning mongrel" load balancing challenge. 
(i.e. the problems where mongrels are loaded up with requests 
irrespective of their availability, leaving some mongrels idle and some 
overloaded.)

I'll give you a simple example: we have to build admin tools 
periodically. It's possible to make these tools spin off background 
processes but that's more time consuming to build and debug. Since 
these tools are just basic admin utilities that we want to invest as 
little time as possible in them: their initial functionality is 95% of 
their overall value. So for example one of these tools lets us bulk 
manage photos and can take 10 seconds to return. Because of 
mongrel/nginx/load balance architecture, we can run into performance 
trouble if we aren't careful at what time of day we use the tool.

You can complain about my sloppy software architecture but I'll 
complain that I'm running a business and need to invest most in what 
returns the most value to our customers. But I'd prefer to just agree 
not to start that discussion. [smile]

If I understand what's being discussed (not a given) the system Robert 
is proposing would mean that a mongrel would only get requests from 
port 80 when it was ready to call "receive()" again from the IP stack. 
So mongrels would consume what they can off a common stack.

This would mean that I don't have to balance all my Rails processes to 
keep them returning results at roughly equal intervals. If my servers 
are heavily loaded now, it seems like a slow returning mongrel can 
cause havoc even if it's just slow by a couple of seconds..

So given the mongrels a common pool of requests to consume from and 
using such a low level pool such as an IP port seems great, and I'd 
vote for it. The fact that my development box doesn't run against the 
same code is totally ok.

I'm sure Windows people who run in production will have other opinions 
but this idea, if it's practical, seems very elegant and useful. +1

Steve



More information about the Mongrel-users mailing list