javascript - 在 Node 中的进程之间发送数据是否昂贵/高效？

Question

Node 允许您生成子进程并在它们之间发送数据。例如，您可以使用它来执行一些阻塞代码。

文档说“这些子 Node 仍然是 V8 的全新实例。假设每个新 Node 至少需要 30 毫秒的启动时间和 10mb 的内存。也就是说，您不能创建数千个子 Node 。”

我想知道它是否有效，我是否应该担心一些限制？这是示例代码:

//index.js
var childProcess1 = childProcess.fork('./child1.js');

childProcess1.send(largeArray);

childProcess1.once('message', function(formattedData) {
  console.log(formattedData);
  return false;
});



//child1.js
process.on('message', function(data) {

  data = format(data); //do smth with data, then send it back to index.js

  try{
    process.send(data);
    return false;
  }
  catch(err){
    console.log(err);
    return false;
  }

});

Answer 1

文档告诉您启动新的 Node 进程是(相对)昂贵的。每次需要工作时都 fork() 是不明智的。

相反，您应该维护一个长期运行的工作进程池——就像线程池一样。在您的主进程中排队工作请求，并在空闲时将它们分派(dispatch)给下一个可用的工作人员。

这给我们留下了一个关于 Node IPC 机制的性能概况的问题。当您fork() 时，node 会自动在子进程上设置一个特殊的文件描述符。它使用它通过读取和写入以行分隔的 JSON 在进程之间进行通信。基本上，当您 process.send({ ... }) 时， Node JSON.stringify 将其写入序列化字符串并将其写入 fd。接收进程读取此数据，直到遇到换行符，然后 JSON.parses 它。

这必然意味着性能将在很大程度上取决于您在进程之间发送的数据的大小。

我已经粗略地进行了一些测试，以更好地了解这种性能。

首先，我向 worker 发送了 N 字节的消息，worker 立即以相同长度的消息响应。我在我的四核超线程 i7 上尝试了 1 到 8 个并发工作器。

我们可以看到，拥有至少 2 个 worker 对原始吞吐量有利，但超过 2 个基本上无关紧要。

接下来，我向 worker 发送了一条空消息，worker 立即回复了一条 N 字节的消息。

令人惊讶的是，这没有任何区别。

最后，我尝试向 worker 发送 N 字节的消息，它立即返回一条空消息。

有趣 — 性能不会随着消息的增大而迅速下降。

要点

• 接收大消息比发送它们稍微贵一些。为了获得最佳吞吐量，您的主进程不应发送大于 1 kB 的消息，并且不应接收大于 128 字节的消息。

• 对于小消息，IPC 开销约为 0.02 毫秒。这个小到足以在现实世界中无关紧要。

重要的是要认识到消息的序列化是一个同步的、阻塞的调用；如果开销太大，你的整个 Node 进程将在发送消息时被卡住。这意味着 I/O 将被饿死，您将无法处理任何其他事件(如传入的 HTTP 请求)。那么可以通过 Node IPC 发送的最大数据量是多少？

超过 32 kB 时事情变得非常糟糕。 (这些是每条消息；双倍以获得往返开销。)

这个故事的寓意是你应该:

• 如果输入大于 32 kB，想办法让您的工作人员获取实际数据集。如果您要从数据库或其他网络位置提取数据，请在 worker 中执行请求。不要让 master 获取数据，然后尝试在消息中发送它。该消息应该只包含足以让工作人员完成其工作的信息。将消息视为函数参数。

• 如果输出大于 32 kB，想办法让工作人员在消息之外传递结果。写入磁盘或 send the socket to the worker以便您可以直接从工作进程响应。