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 On Friday, November 22, 2013 8:12:41 AM UTC-8, 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.
