On 10/23/07, Robert Mela <[EMAIL PROTECTED]> 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 _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
