Just wanted to bump this, as we're starting to attack this problem on our production servers.
We're planning on phasing out a monolithic django app with our new frontend, and while performance stats we're getting from our development branches are already pretty good, we'd like to really tune this up so we get the most out of the handful of machines we have. So, with that in mind, it would be interesting to look at this problem from the perspective of multiple machines, and sharing some kind of round robin approach, or maybe lightweight messaging between a cluster of servers that are spun up and ready to accept connections...? We're fortunate in that we don't have much in the way of CPU bound tasks (yet), but do a lot of API bashing, which should help. Is there something that we could use that is already out there..? Maybe as a base which we can pick up and customise for our own ends, and then share the code..? We're especially interested in doing multiple parallel A/B/C/... testing for various user cohorts too. (ie, have some test on a branch which we can deploy, then integrate it into the cluster with determined conditions for access, percentage of traffic, particular user agents, location, etc.. ). Any experiences which people on the list would like to share? Seems like it could be an interesting topic, as in, one that appears superficially trivial, but actually fraught with potential pitfalls... On Saturday, 23 November 2013 16:06:01 UTC+1, Ben Noordhuis wrote: > > On Sat, Nov 23, 2013 at 3:01 AM, Marco Rogers > <marco....@gmail.com<javascript:>> > wrote: > > I have a naive question here. If cluster doesn't know if the worker is > busy, > > what happens when a new connection comes in and it is still busy? Do > > requests queue at each worker? What behavior should be expected if > you're > > using round robin with lots of busy workers? I'm thinking of the Heroku > > problem, which I feel like I read enough about to understand > conceptually. > > This isn't my area, so when you answer you can assume I don't know what > the > > hell I'm talking about :) > > > > :Marco > > The cluster module operates at the level of connections, not requests. > It's possible for a connection to enter a kind of limbo when it's > been handed off to a worker but that worker is too busy to actually > accept it. (But only for a single connection because the worker is > removed from the pool of ready workers until it acknowledges that it > has received the connection.) > > It's not possible to fix that with some kind of timeout in a race-free > way. Handing off the connection to another worker if the first one > doesn't ack in a timely manner is subject to race conditions because > the first worker could send the ack right when the connection is > handed off to the other worker. > > As a general observation, the advice that you should not block the > event loop for long periods of time also applies to clustered > applications. > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
