[Mongrel] Shared listening sockets
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
> listen on the same TCP/IP socket. The trick of course is that all
> processes are in the same process group, and the socket is opened by
> shared parent. The OS somehow was managing queuing up the various
> calls to accept() on that socket. Since the watchdog parent /
> child servers is a common, this was a workable solution on the
> of Linux we were using.
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
>well worth investigation for what we have planned.
>Thank you kindly for this,
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
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
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
More information about the Mongrel-users