4 ms·

I dabbled with worker threads in the past. It feels like you are orchestrating a bunch of node.js instances (workers) with one single threaded entry point, whic

by sod 5y ago

I dabbled with worker threads in the past. It feels like you are orchestrating a bunch of node.js instances (workers) with one single threaded entry point, which is now your new bottleneck. It seems way easier and faster to instead start as many node.js instances as you need and distribute the load via nginx reverse proxy. It's unfortunate that ssr for client frameworks has to run in node.js, which is rather slow. But that shouldn't invite someone to stack more server javascript on top of it. Maybe someday someone is brave enough to write a frontend framework that uses a compiled language (rust, go, java?), that can also compile to javascript for the client, but renders crazy fast in ssr.

eyelidlessness 5y ago
> I dabbled with worker threads in the past. It feels like you are orchestrating a bunch of node.js instances (workers) with one single threaded entry point, which is now your new bottleneck. Depending on use case/workload, the bottleneck is mostly startup time. Message passing is much faster than most people think, and the main thread ideally is primarily just doing that and getting out of the way. Spinning up new processes is more expensive and so is IPC. Of course if you don’t need coordination… > It seems way easier and faster to instead start as many node.js instances as you need and distribute the load via nginx reverse proxy. Sure. If you’re running a stateless server. To be honest it’s not clear to me whether that’s the case here. But for other use cases where coordination is needed and which would benefit from concurrency, worker threads are often the best solution for Node. > It's unfortunate that ssr for client frameworks has to run in node.js, which is rather slow. But that shouldn't invite someone to stack more server javascript on top of it. Maybe someday someone is brave enough to write a frontend framework that uses a compiled language (rust, go, java?), that can also compile to javascript for the client, but renders crazy fast in ssr. There are lots of solutions in this space. Whether they’re worth adopting largely depends on their maturity and your team’s ability/willingness to adopt them.
- sod 5y ago
  > which would benefit from concurrency, worker threads are often the best solution for Node. But is it really concurrent though? Each request in the end is still processed by a single node worker which is limited to a single cpu core. Except you manage to distribute parts of the renderer to different workers in parallel. I tried that once as well, render the header, footer and body in 3 different workers. But in the end this consumed 2x as much cpu thus needing 8 workers instead of just plain 4 node servers. And the threads stepped on each other feet due workers being itself single threaded, so the 99%tile got worse/unpredictable. All of my knowledge is of course biased by using angular, and trying to parallelize angular comes with some overhead due to dependency injection and having to spin up most of the app even though you may only want the header. So I could see how react.js ssr could indeed be split up easier. Didn't had the pleasure to benchmark this yet though.
  - eyelidlessness 5y ago
    > But is it really concurrent though? Yes. > Each request in the end is still processed by a single node worker which is limited to a single cpu core. Even without worker threads it’s still concurrent, every async operation suspends and yields to the event loop. The difference is cooperative concurrency (the default Node concurrency model) and whatever concurrency you want with threads. > Except you manage to distribute parts of the renderer to different workers in parallel. I tried that once as well, render the header, footer and body in 3 different workers. But in the end this consumed 2x as much cpu thus needing 8 workers instead of just plain 4 node servers. And the threads stepped on each other feet due workers being itself single threaded, so the 99%tile got worse/unpredictable. Your workload very likely wasn’t CPU bound and probably benefited more from the traditional event loop. Most React use cases will be the same.

by sod 5y ago

eyelidlessness 5y ago

> I dabbled with worker threads in the past. It feels like you are orchestrating a bunch of node.js instances (workers) with one single threaded entry point, which is now your new bottleneck. Depending on use case/workload, the bottleneck is mostly startup time. Message passing is much faster than most people think, and the main thread ideally is primarily just doing that and getting out of the way. Spinning up new processes is more expensive and so is IPC. Of course if you don’t need coordination… > It seems way easier and faster to instead start as many node.js instances as you need and distribute the load via nginx reverse proxy. Sure. If you’re running a stateless server. To be honest it’s not clear to me whether that’s the case here. But for other use cases where coordination is needed and which would benefit from concurrency, worker threads are often the best solution for Node. > It's unfortunate that ssr for client frameworks has to run in node.js, which is rather slow. But that shouldn't invite someone to stack more server javascript on top of it. Maybe someday someone is brave enough to write a frontend framework that uses a compiled language (rust, go, java?), that can also compile to javascript for the client, but renders crazy fast in ssr. There are lots of solutions in this space. Whether they’re worth adopting largely depends on their maturity and your team’s ability/willingness to adopt them.

sod 5y ago
> which would benefit from concurrency, worker threads are often the best solution for Node. But is it really concurrent though? Each request in the end is still processed by a single node worker which is limited to a single cpu core. Except you manage to distribute parts of the renderer to different workers in parallel. I tried that once as well, render the header, footer and body in 3 different workers. But in the end this consumed 2x as much cpu thus needing 8 workers instead of just plain 4 node servers. And the threads stepped on each other feet due workers being itself single threaded, so the 99%tile got worse/unpredictable. All of my knowledge is of course biased by using angular, and trying to parallelize angular comes with some overhead due to dependency injection and having to spin up most of the app even though you may only want the header. So I could see how react.js ssr could indeed be split up easier. Didn't had the pleasure to benchmark this yet though.
- eyelidlessness 5y ago
  > But is it really concurrent though? Yes. > Each request in the end is still processed by a single node worker which is limited to a single cpu core. Even without worker threads it’s still concurrent, every async operation suspends and yields to the event loop. The difference is cooperative concurrency (the default Node concurrency model) and whatever concurrency you want with threads. > Except you manage to distribute parts of the renderer to different workers in parallel. I tried that once as well, render the header, footer and body in 3 different workers. But in the end this consumed 2x as much cpu thus needing 8 workers instead of just plain 4 node servers. And the threads stepped on each other feet due workers being itself single threaded, so the 99%tile got worse/unpredictable. Your workload very likely wasn’t CPU bound and probably benefited more from the traditional event loop. Most React use cases will be the same.