node.js - 快速应用程序中的工作线程

Question

我有一个 express 后端应用程序，它监听来自 Web 应用程序的 http 请求。此后端应用程序在 AWS ECS Fargate 上运行。

所以我的问题是，在这个后端应用程序中使用 Node.js 中的多线程、工作线程是否有意义？端点中既有 CPU 密集型函数，也有非 CPU 密集型函数。例如，无论调用强度如何，我是否应该立即将任何传入请求分发给其他线程，以便主线程永远不会被阻塞？或者我应该只在密集型作业等上使用多线程。

非常感谢关于此主题的任何建议、利弊。

Answer 1

像这样的问题最终只能通过在代表性负载下分析系统才能真正得到回答。这是因为我们对什么占用 CPU 以及占用多少 CPU 的猜测很少非常好 - 这些东西必须经过测量才能真正知道。

也就是说，您可以考虑一些通用的设计准则:

1. 如果您有事先认为可能会占用 CPU 资源的特定请求，那么您可能需要考虑将这些请求放入由线程池提供服务的队列中。

2. 如果您事先相信特定的请求实际上只是在执行非阻塞 I/O，那么根本不需要通过线程使这些请求变得复杂。主线程可能可以很好地处理这些问题。

3. 如果您的请求中只有相对较小的一部分是 CPU 密集型的，最简单的设计可能是使用 nodejs 集群模块，让它将您的请求分散到 CPU 中，自行计算(没有任何其他主要的设计更改)将使任何受 CPU 限制的请求脱离主循环。如果你的请求中有很大一部分是 CPU 绑定(bind)的，并且你想优先处理非 CPU 请求以便它们总是很快，那么你可能会更好地使用线程池将 CPU 密集型请求传递给非 CPU 请求-CPU 繁重的请求不会被它们阻止。

So my question is, does it makes sense use multithreading, worker-threads in Node.js, in this backend application?

是的，在某些情况下。但是，何时添加这一额外的复杂层实际上取决于请求中 CPU 使用率的具体指标。

For instance should I just distribute any incoming request right away ,regardless of the intensity of the call, to other threads so that Main thread is never blocked? Or should I only use multithreading on intensive jobs etc.

这取决于您希望如何确定不同请求的优先级。如果您希望请求按 FIFO 顺序排列优先级，其中每个请求都根据到达时间按顺序开始，而不管是什么类型的请求，那么是的，您可以将所有请求分配给线程。事实上，为此使用集群模块可能更容易，因为它就是这样做的。另一方面，如果您希望非 CPU 密集型请求始终快速运行，而不必在 CPU 密集型请求之后等待，那么您可能希望仅将 CPU 密集型请求推送到由线程池。这样一来，主线程就可以立即处理非 CPU 密集型请求，而不管当前线程池中有多少 CPU 密集型请求正在处理。