We 30x'd our Node parallelism • Hacker News Board

Re: We 30x'd our Node parallelism

#251

Post by davedx » Sat, Dec 14, 2019, 1:13 PM UTC

dmitriid wrote: post #37

davedx wrote: post #27

Earlier quoted context omitted.

> trivially blocked by very simple programmer errors Can you give an example please? I think it's much easier to block a thread with C#'s async programming model than node's...

Node only has one thread. Everything else follows.

Nodejs has an event loop running in a single thread, but most calls you'll do will be async (and therefore let other operations continue to be executed by the event loop). The entire programming ecosystem is async by default.

The only thing I can think of where a programmer could "easily" block the event loop would be if they explicitly use sync filesystem or other blocking calls instead of the async API. But in any project with reasonable code review I don't think this would happen.

Re: We 30x'd our Node parallelism

#252

Post by neebz » Sat, Dec 14, 2019, 1:15 PM UTC

NathanKP wrote: post #103

kevstev wrote: post #67

I was building scalable node applications a few years ago for a very large e-commerce player- millions of customers. I think node.js is a great platform, but its apparent simplicity means there are hordes, and I mean like 90+% of the community, that can "just get things done" without understanding what is going on under the hood at all. And to be fair, for most startupy types of companies that need to iterate fast, t…

This is why I recommend that anyone running Node in production use a tracing tool like New Relic. It's super easy to see what is blocking the event loop. Just choose a duration (say 10ms) and look for any execution spans that are longer than that duration. Ideally you want to be yielding back to the event loop at least every 1 ms. Anything that takes too long without yielding will show up as a latency delay before yo…

How exactly do you use NewRelic to see what is blocking the event loop? I thought we always needed Flame Graphs for it (which NR doesn't provide)

Re: We 30x'd our Node parallelism

#253

Post by megous » Sat, Dec 14, 2019, 1:18 PM UTC

phoe-krk wrote: post #192

megous wrote: post #122

Earlier quoted context omitted.

JavaScript doesn't require event loop design. You can do a PHP like backend design with JS, where each request is handled by a fresh process, and all JS functions block. There's nothing in the language that prevents this. Some features would become unusable, like Promises and async/await, but those would be worthless in such a design anyway.

Nobody does it. Nobody implemented it yet. Nobody made it production ready. That is what a few minutes of googling gave me. As much as I'd like to see it, your JS without an event loop is a purely theoretical construct so far.

I did blocking design using Duktape for my runtime Linux distro reinstallation tool and some other projects. It works fine and it's easier than implementing async aware bindings.

I wouldn't implement it for the HTTP server/backend use case, because I find the blocking/share nothing architecture of PHP limiting.

The point is the language doesn't prevent this kind of architecture.

Re: We 30x'd our Node parallelism

#254

Post by dmitriid » Sat, Dec 14, 2019, 2:01 PM UTC

davedx wrote: post #251

dmitriid wrote: post #37

Earlier quoted context omitted.

Node only has one thread. Everything else follows.

Nodejs has an event loop running in a single thread, but most calls you'll do will be async (and therefore let other operations continue to be executed by the event loop). The entire programming ecosystem is async by default. The only thing I can think of where a programmer could "easily" block the event loop would be if they explicitly use sync filesystem or other blocking calls instead of the async API. But in any…

> The only thing I can think of where a programmer could "easily" block the event loop would be

Parsing JSON. Or executing a regex. Or anything, really, that blocks the thread: https://nodejs.org/en/docs/guides/dont-block-the-event-loop/

There's no magic

Re: We 30x'd our Node parallelism

#255

Post by pdimitar » Sat, Dec 14, 2019, 2:07 PM UTC

timmy-turner wrote: post #250

pdimitar wrote: post #150

...Or you could just use Erlang or Elixir, where concurrency and parallelism come pretty much out of the box, with very little effort required for you to fine-tune the desired policy / strategy. The insistence on using Javascript is just beyond lunacy at this point.

Well, if Elixir had a Typesystem like Javascript has, I'd instantly switch to it. But atm I'm staying with Node because of Typescript.

True, it doesn't have it. Between pattern matching and function guards however, it has a decent way to protect against common errors.

The true treasure is Erlang / Elixir's runtime though. The parallelism, the self-healing, the preemptive scheduling.

Re: We 30x'd our Node parallelism

#256

Post by rmetzler » Sat, Dec 14, 2019, 2:15 PM UTC

rdsubhas wrote: post #125

stickfigure wrote: post #74

Earlier quoted context omitted.

I'd recommend moving away from Node... Taking a wild guess: Some of their bank integrations probably require browser automation. If you're doing browser automation, the best tool for the job is (currently) Puppeteer, which runs on Node. There are other third-party language bindings for the Chrome dev tools protocol, but Puppeteer is developed by Google as a first-class citizen alongside Chrome.

4000 chrome instances? Probably not. Here I am trying to run 4 chrome instances in parallel in CI without crashing.

Check out the selenoid project. It’s like a selenium grid but dockerized with novnc, etc.

Re: We 30x'd our Node parallelism

#257

Post by dmitriid » Sat, Dec 14, 2019, 3:37 PM UTC

coddle-hark wrote: post #249

dmitriid wrote: post #211

Earlier quoted context omitted.

You say no it doesn't and then speak about concurrency models for single-threaded systems. Choose one :) Node can't not be single-threaded. Because Javascript is. Node.js is single threaded. It has a single event loop in a single thread, and all the "concurrency" is simply queued on that loop. It offloads some tasks to libuv for some system-related tasks but that's it. And the thread pool that libuv creates is very l…

You’re focusing on single-threadedness like that’s a problem but it’s not. For example, you can run multiple processes on a single core system just fine — even if one of those processes hangs. AFAIK there’s nothing in the JS language that forces a single-threaded implementation. I think the real reasons that Node is single threaded are a) legacy and more importantly b) a lot of existing code would break if events wer…

> you can run multiple processes on a single core system just fine — even if one of those processes hangs.

Yes, I can. Node.js doesn't do that.

Re: We 30x'd our Node parallelism

#258

Post by dmitriid » Sat, Dec 14, 2019, 3:40 PM UTC

willglynn wrote: post #244

dmitriid wrote: post #211

Earlier quoted context omitted.

You say no it doesn't and then speak about concurrency models for single-threaded systems. Choose one :) Node can't not be single-threaded. Because Javascript is. Node.js is single threaded. It has a single event loop in a single thread, and all the "concurrency" is simply queued on that loop. It offloads some tasks to libuv for some system-related tasks but that's it. And the thread pool that libuv creates is very l…

Not OP, but… concurrency is not the same as parallelism. This is an important hair to split: https://stackoverflow.com/a/24684037/1026671 "Concurrency" doesn't warrant scare quotes even when describing a single threaded program. It's true that Node.js allows one task to block many others, but that's an implementation detail of Node.js, not a guaranteed result which necessarily applies to any program using only one OS…

I never said anything about other programs. I never said that other single-threaded programs don't suffer from the same problems. That's is sort of the point. Node.js is single-threaded and, as a result, had all the same problems a single-threaded programs has. And no amount of hand-waving can change that fact.

Re: We 30x'd our Node parallelism

#259

Post by NathanKP » Sun, Dec 15, 2019, 2:53 AM UTC

neebz wrote: post #252

NathanKP wrote: post #103

Earlier quoted context omitted.

This is why I recommend that anyone running Node in production use a tracing tool like New Relic. It's super easy to see what is blocking the event loop. Just choose a duration (say 10ms) and look for any execution spans that are longer than that duration. Ideally you want to be yielding back to the event loop at least every 1 ms. Anything that takes too long without yielding will show up as a latency delay before yo…

How exactly do you use NewRelic to see what is blocking the event loop? I thought we always needed Flame Graphs for it (which NR doesn't provide)

Flame graph is only needed if you are having a lot of trouble pinning down the exact call that is taking a long time. In most cases I've found traces to be all I needed. For example if I see that this span of execution took longer than expected and I read through that code and see a bunch of JSON serialization its pretty obvious.

To be honest that comes with a lot of Node.js experience though. You probably need flame graphs to start out with, but eventually I find New Relic traces to be all I need, as I already have a sense for the relative CPU weight of the various calls inside a trace span.

Re: We 30x'd our Node parallelism

#260

Post by davedx » Sun, Dec 15, 2019, 3:33 PM UTC

dmitriid wrote: post #254

davedx wrote: post #251

Earlier quoted context omitted.

Nodejs has an event loop running in a single thread, but most calls you'll do will be async (and therefore let other operations continue to be executed by the event loop). The entire programming ecosystem is async by default. The only thing I can think of where a programmer could "easily" block the event loop would be if they explicitly use sync filesystem or other blocking calls instead of the async API. But in any…

> The only thing I can think of where a programmer could "easily" block the event loop would be Parsing JSON. Or executing a regex. Or anything, really, that blocks the thread: https://nodejs.org/en/docs/guides/dont-block-the-event-loop/ There's no magic

Well it's a question of magnitude. In theory everything blocks the loop even if it's only 1 CPU cycle before it yields.

In practice I've rarely seen production nodejs applications cause significant CPU blocking issues. Huge JSON parses sometimes, yes, but then it has to be one hell of a payload to cause any significant issue.

Regexes? Have you really seen regexes block CPU for significant time relative to the rest of the application? I'm sure it's possible with a crazy enough runaway pattern, but I've never seen it happen.

I really don't understand what people are getting at here. Nodejs is an async programming model, it's non-blocking by default. Are the people saying it's trivial to break nodejs developers?