网络并行化是否对Node.js工作者有用？

问题描述

我正在尝试使用Node.js worker_threads模块，目的是“收集”对不同API的许多请求的结果。这对工人来说是个好用例吗？

例如：

import { Worker } from 'worker_threads'

const API_ADDRESSES = [... maybe 20 different URIs]

const results = await Promise.allSettled(
  API_ADDRESSES.map(
    uri => new Promise(
      (resolve,reject) => {
        const worker = new Worker(... filepath.js,{ workerData })
        worker.on('message',resolve)
        worker.on('error',reject)
      }
    )
  )
)

// The Worker then uses axios/node-fetch/etc to make a network request and returns data as a message

如果这对工人不是一个好用例，那么哪种方法更好？另外，如果不是一个好主意，为什么对工人来说这不是一个好用例？

尝试过此方法后，效果似乎不错，但我真的不知道如何从性能角度对其进行评估。

====编辑

我之所以尝试使用这种方法的原因

await Promise.allSettled(API_ADDRESSES.map(uri => fetch(uri,{....})))

每个结果我可能想要在返回之前处理响应（即结果可能是很多我想要相关系数的数字）。

解决方法

网络并行化是否要求Node.js工作者很好地利用它？

不是。节点已经并行化网络请求。

CPU请求繁重的网络请求处理的并行化是否对Node.js工作者有用？

可能是。如果网络请求的处理将花费大量时间，则并行执行该处理可带来性能上的好处。您可以通过对这两种方法进行基准测试来确定这一点。

请注意，这里的关键运算符是您正在并行化大量的CPU处理。网络请求部分本身已经非常有效地并行化了。

,

基本上，Node.js中的http请求不是阻塞操作（多数情况下是对的）。因此在这里使用工人是多余的，不建议这样做。

什么是更好的方法

这可能因情况而异，但这在大多数情况下就足够了：

await Promise.all([fetch(...),fetch(...),...]);

更多信息，here。

,

嗯，这似乎很好用，因为您希望在不同的线程中完成呼叫。但是众所周知，NodeJS已经具有异步IO。因此，要进行网络工作，简单的请求库用法就足够了。

另一方面，

worker_threads较重，以包含CPU使用情况。并且工作线程通过IPC调用相互通信，因为它们的行为就像一个完全独立的进程生成物。

worker_threads的一些用例是

1. 创建一个http_servers集群。
2. 在新线程上分配CPU密集型作业。 等等...