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

Re: We 30x'd our Node parallelism

#31

Post by earthboundkid » Fri, Dec 13, 2019, 3:53 PM UTC

phoe-krk wrote: post #5

7777fps wrote: post #2

> We were running 4,000 Node containers (or "workers") for our bank integration service. The service was originally designed such that each worker would process only a single request at a time. This design lessened the impact of integrations that accidentally blocked the event loop, and allowed us to ignore the variability in resource usage across different integrations. But since our total capacity was capped at 4,0…

> I thought one of the key selling points with Node was an fully async standard library, enabling better scaling in process. We still have an event loop that is trivially blocked by very simple programmer errors, destroying the whole advantage that you describe here. The fact that Node ships a fully asynchronous standard library doesn't in any way fix the fact that Node is a runtime for a language that itself is a mi…

Async is just modern cooperative multitasking, and just like the 90s, it's easy to accidentally lock the whole system.

Re: We 30x'd our Node parallelism

#32

Post by ilaksh » Fri, Dec 13, 2019, 3:55 PM UTC

7777fps wrote: post #2

> We were running 4,000 Node containers (or "workers") for our bank integration service. The service was originally designed such that each worker would process only a single request at a time. This design lessened the impact of integrations that accidentally blocked the event loop, and allowed us to ignore the variability in resource usage across different integrations. But since our total capacity was capped at 4,0…

They didn't actually understand Node very well at first and then later they figured it out.

Re: We 30x'd our Node parallelism

#33

Post by Scarbutt » Fri, Dec 13, 2019, 3:56 PM UTC

I don't want to be that guy, but why did they start with nodejs for something like this instead of using the JVM or Go?

Re: We 30x'd our Node parallelism

#34

Post by bjacokes » Fri, Dec 13, 2019, 3:57 PM UTC

tyingq wrote: post #10

"Only 10% of Plaid's data pulls involve a user who is present" Since they provide an API, it seems like some of the calls where they think a user isn't present might actually have one present.

We thread knowledge of whether a data pull was initiated by the API or by our cron-style service into our load-balancing layer, so this ends up being pretty straight-forward.

Re: We 30x'd our Node parallelism

#35

Post by kreetx » Fri, Dec 13, 2019, 3:58 PM UTC

spamizbad wrote: post #14

The only way this makes sense to me is if they have to contend with lots of expensive parsing, event sequencing, and throttling requirements. Payment APIs, bank websites, etc can be quite byzantine. I could understand how one might code yourself into a corner with a monolithic node app and basically just say "F-it, we're doing this synchronously!" I don't even think it's a terribly bad thing to do assuming it favors…

Haskell also has very nice concurrency IMO.

Re: We 30x'd our Node parallelism

#36

Post by deedubaya » Fri, Dec 13, 2019, 3:58 PM UTC

A good example of avoiding premature optimization. I'd imagine delaying tackling this problem freed them up to tackle problems that impact users.

Re: We 30x'd our Node parallelism

#37

Post by dmitriid » Fri, Dec 13, 2019, 4:00 PM UTC

davedx wrote: post #27

phoe-krk wrote: post #5

Earlier quoted context omitted.

> I thought one of the key selling points with Node was an fully async standard library, enabling better scaling in process. We still have an event loop that is trivially blocked by very simple programmer errors, destroying the whole advantage that you describe here. The fact that Node ships a fully asynchronous standard library doesn't in any way fix the fact that Node is a runtime for a language that itself is a mi…

> 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.

Re: We 30x'd our Node parallelism

#38

Post by mceachen » Fri, Dec 13, 2019, 4:00 PM UTC

In case anyone else gets excited by JSONStream, know that the package hasn't been updated in over a year, and the GitHub repo was archived by the author with no link to a successor.

Re: We 30x'd our Node parallelism

#39

Post by caiobegotti » Fri, Dec 13, 2019, 4:00 PM UTC

Scarbutt wrote: post #33

I don't want to be that guy, but why did they start with nodejs for something like this instead of using the JVM or Go?

They probably already had some decent experience with Node and it solved their initial problem well enough, refactoring or rewriting costs usually make engineering managers frown upon (wrongfully) and so it becomes much harder to fix this in the long term.

Re: We 30x'd our Node parallelism

#40

Post by jononor » Fri, Dec 13, 2019, 4:00 PM UTC

phoe-krk wrote: post #24

nicoburns wrote: post #9

Earlier quoted context omitted.

> We still have an event loop that is trivially blocked by very simple programmer errors, destroying the whole advantage that you describe here. So they fixed the issue that some requests blocked... by making all requests blocking.

This is the worst kind of software engineering. There is a massive deadlocking design mistake in the centre of the language - literally a huge red button with DO NOT PRESS printed on it. Thousands of programmers pass it by every single day, or hour, or minute, and the creators of the runtime insist that it is impossible to fix that button whatsoever; instead, all users need to work around it by ensuring that their co…

The blog in question indicates some uncommon and questionable engineering practices with Node.js. There are likely hundreds of success stories for every one like that.

The first Node.js service I wrote and maintained, processed thousands of requests in parallel and was successfully in production until the company it was developed for ran out of money.