I think that works for us at the moment, as it seems comparable with the behavior of the current implementation, which, while it doesn't really know how busy a worker is, also won't receive requests until the worker has a chance to hit the event loop again.
On Friday, November 22, 2013 10:12:41 AM UTC-6, Ben Noordhuis wrote: > > On Fri, Nov 22, 2013 at 3:30 PM, Andrew D <dep...@gmail.com <javascript:>> > wrote: > > I have a question that is not immediately obvious after reading these > two > > links. How well does Node's round robin work with requests that produce > > significantly varied workloads on the server? > > I don't mean, how well does the round robin algorithm work with varies > > workloads, since I already know the answer to that... what I mean is, is > > Node smart enough to skip workers that are still busy from the last > round > > robin request sent to them? In other words, if a worker is busy on a CPU > > bound function, will it be skipped until it gets freed up again? > > We have a development platform that is similar to Meteor ( > > http://www.meteor.com/<http://www.google.com/url?q=http%3A%2F%2Fwww.meteor.com%2F&sa=D&sntz=1&usg=AFQjCNFsYVXZEstozl04pf0AN_kdnHh4dA>) > > in that code transparently runs on the client or > > server. All processing is done in JavaScript, which means some functions > are > > way more CPU bound than others - and the creative developers using this > > platform use it for all sorts of things (data processing, image > processing, > > DB access, etc). > > What we like about the current clustering is that a request is not sent > to a > > worker that is spinning away on some CPU bound function. Yes, the > current > > approach does tend to send requests to the same workers when they are > not > > busy, so round robin would be awesome to fix that issue... but is the > > current round robin smart enough to skip workers that are busy? > > The answer to that question is mostly 'no'. The master won't send new > connections to workers that haven't acknowledged receipt of the last > one yet but, apart from that, it doesn't really know whether a worker > is busy or not. > > We'll undoubtedly address that in due time but that requires > considerable engineering effort. Naively sending "I'm busy" / "I'm > idle" messages back and forth whenever user code is executed leads to > serious performance degradation because you quickly hit a point where > you spend all your CPU time processing messages and not doing anything > useful. There are solutions to that issue (mostly involving tricks > with shared memory) but none are easy to implement in a cross-platform > manner. > -- -- 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.
