3 ms·

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

by 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

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