Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js worker threads are problematic, but they work great for us

inngest.com

Post reply on HN
Print view View original

31–35 of 35 posts

Re: Node.js worker threads are problematic, but they work great for us

#31

Post by baublet »

n_e wrote: post #9
baublet wrote: post #7

Reading the article, I didn’t see this answered: why not scale to more nodes if your workload is CPU bound? Spin off 1 cpu and a few gb of ram container and scale that as wide as you need? e.g., this certainly helps when the event loop is blocked, but so could FFI calls to another language for the CPU bound work. I’d only reach for a new Node thread if these didn’t pan out, because there’s usually a LOT that goes int…

> but so could FFI calls to another language for the CPU bound work Worker threads can be more convenient than FFI, as you don't need to compile anything, you can reuse the main application's functions, etc.

True! Although in a lot of Node you DO have a compile chain (typescript) you need to account for. There’s a transactional cost there to get these working well, and only sharing the code it needs. These days it’s much smaller than it used to be, though, so worker functions are seeing more use.

I make my comment to note tho that in many envs it’s easier to scale out than account for all the extra complications of multiple processes in a single container.

Re: Node.js worker threads are problematic, but they work great for us

#32

Post by whizzter »

goldenarm wrote: post #15

The lack of backpressure handling nor promise api for postMessage is also quite annoying, I had many OOMs because of it.

It's not ideal, the api is kind of low-yet-high-level and that brings some complications.

Move backpressure handling onto the task producer and use a SharedArrayBuffer between the producer and worker, where the worker atomically updates a work-count or current work item ID in that SharedArrayBuffer that the producer can read (atomically) to determine how far along the worker has gotten.

Re: Node.js worker threads are problematic, but they work great for us

#33

Post by shepardrtc »

ptrwis wrote: post #5

I'm currently writing simulations of trading algorithms for my own use. I'm using worker_threads + SharedArrayBuffer and running them in Bun. I also tried porting the code to C# and Go, but the execution time ended up being very similar to the Bun version. NodeJS was slower. Only C gave a clear, noticeable performance advantage — but since I haven't written C in a long time, the code became significantly harder to ma…

I built an algorithmic trader years ago just using Python, but for the hot paths I gave each algorithm its own function in its own file, and then I would compile the files with Cython. The speedup was pretty significant. I barely wrote any "Cython" stuff (meaning declaring variables and other minor assists). The code is still very much python, just with a few little extras that are easy to understand.

Re: Node.js worker threads are problematic, but they work great for us

#34

Post by goodoldneon »

baublet wrote: post #7

Reading the article, I didn’t see this answered: why not scale to more nodes if your workload is CPU bound? Spin off 1 cpu and a few gb of ram container and scale that as wide as you need? e.g., this certainly helps when the event loop is blocked, but so could FFI calls to another language for the CPU bound work. I’d only reach for a new Node thread if these didn’t pan out, because there’s usually a LOT that goes int…

> Reading the article, I didn’t see this answered: why not scale to more nodes if your workload is CPU bound?

It's an SDK that runs in users' apps. So userland code blocks the event loop, preventing outgoing heartbeats from the SDK

Re: Node.js worker threads are problematic, but they work great for us

#35

Post by goodoldneon »

socketcluster wrote: post #4

I like Node.js' simple and fully isolated concurrency model. You shouldn't be blocking the main event loop for 30 seconds! The main event loop is not intended to be used for heavy processing. You can just set up a separate child process for that. The main event loop which handles connections should just co-ordinate and delegate work to other programs and processes. It can await for them to complete asynchronously; th…

> You shouldn't be blocking the main event loop for 30 seconds! The main event loop is not intended to be used for heavy processing.

This article is talking about an SDK that runs in users' apps. Users can run whatever code they want, so the SDK has to find a way to keep sending the outgoing heartbeats

Post reply on HN