node.js - 为什么React `renderToString`方法不使用集群？

Question

为什么问这个问题？

我正在学习有关 js 性能和 Web 渲染的知识。 This post非常有用。

如果您点击一些链接，您将登陆 here并阅读以下内容:

User code in Node.js runs in a single thread, so for compute operations (as opposed to I/O), you can execute them concurrently, but not in parallel.

所以我读过有关 NodeJS 中并发和并行性的内容。我了解到 NodeJS 是:

• 并行 I/O 绑定(bind)任务，因为它由 libuv 处理
• CPU 密集型任务的并发

这解释了为什么 renderToString 是一个缓慢的操作，因为它受 CPU 限制。但似乎有一种方法可以在nodejs中启用CPU密集型任务的并行性:clustering .

问题

这就是我来这里的原因。你知道为什么renderToString不是集群的吗(不知道这是否是有效的英语)？

• 也许太复杂了？
• 也许它无法并行完成？
• 也许由于某种原因它无法提高性能？

我想了解为什么。因为在阅读完这些内容之后，我倾向于认为 NodeJS 在处理 I/O 方面非常高效，但它似乎对于 CPU 密集型任务也很高效，因为您可以创建集群。尽管如此，这似乎并不是微不足道的，并且是在某些特定情况下需要考虑的选择。

因此，这给我们带来了一个额外的问题:nodejs 集群的限制/缺点是什么？ (除了大型项目的设置和维护似乎很复杂之外？)

Answer 1

将抽象放在这个级别是没有意义的。

将 renderToString() 作为集群运行并不难。例如，您可以轻松使用 worker-farm图书馆。

问题是这变得很难以有益的方式使用，因为为每个传入请求构建的数据“存储”必须在 renderToString() 工作的整个组件树的范围内.

也许通过实验 worker threads node.js 库，我们可能会得到一些多线程 renderToString。但是，React 在 SSR(服务器端渲染)方面的工作并不像客户端那么活跃。

也许通过允许 React 暂停树的渲染并启动它的工作，我们最终将拥有一个可以在主线程处理传入请求/操作时继续渲染的线程。