针对cpu密集型任务的子进程?

时间:2013-07-30 20:24:51

标签: node.js

所以我开始将node.js用于我正在做的项目。

当客户端发出请求时,我的node.js服务器从另一个服务器获取一个json,然后将其重新格式化为一个新的json,并将其提供给该客户端。但是,节点服务器从其他服务器获得的json可能非常大,因此“按摩”数据非常麻烦。

过去几个小时我一直在阅读node.js对于cpu任务的效果如何,我看到的主要响应是生成一个子进程(基本上是一个运行不同的.js文件)处理可能阻塞主事件循环的任何cpu密集型任务的节点实例。

因此,假设我有20,000个并发用户,这意味着它会在运行这些子进程时产生20,000个os级别的作业。

这听起来像个好主意吗? (另一个Web服务器只会在同一进程上创建20,000个线程。)

我不确定我是否应该运行子进程。但我确实需要进行非阻塞的cpu密集型任务。我应该做什么的想法?

2 个答案:

答案 0 :(得分:8)

为节点提供支持的V8 Javascript引擎实际上是pretty fast compared to many server-side languages

问题是Node的Evented Model与cooperative multitasking非常相似 - 特定请求的操作将继续,直到它将控制权转回Javascript事件循环,因此高CPU任务将阻塞循环(意味着随机选择的用户将获得完美的性能,另一组将获得超时,而不是使用负载优雅地降低性能。

因此,对于CPU密集型任务,您可以使用多种解决方案:

  1. 您可以像处理管道一样处理您的代码,并在重要的处理块之间简单process.nextTick以减少平均延迟(同时增加绝对最小值),基本上更“合作”并且不允许任何一个请求占用了很长时间的CPU。
  2. 如果您的工作是纯Javascript(不需要Node模块),您可以使用node-webworker-threads库将CPU密集型工作卸载到线程。但是,不断产生新线程可能是一个坏主意,因此您可能需要一个线程池,您可以将这些工作人员从这些工作队员中拉出来并发送回并输出队列。在这种情况下......
  3. 您创建一个子进程工作池并使用相同的排队机制,其中池大小取决于需要CPU密集路径的请求的百分比,请求总数以及这些请求允许的可容忍延迟增加

答案 1 :(得分:-2)

那些不知道如何设计解决方案的人。

NodeJS正是它所说的,它是一个节点,应该这样对待。

在您的示例中,您的节点实例连接到外部api并抓取json进行处理并发回。

即。 1.获取// server.com/getJSON 2.处理json 3.发布// server.com/postJSON

那你做什么? 问问自己时间问题?如果是,那么节点不是解决方案 但是,如果您对原始处理能力更感兴趣,那么而不是在4秒内完成1个请求

您感兴趣的是在10秒钟内完成的200个请求,但每个请求大约需要10秒钟。

诊断您的JSON应该按摩多长时间,如果它少于1秒。 只需运行4个节点实例而不是1个。

然而,如果它比那更复杂,请将json分解成段来处理。并使用异步回调来处理每个段

process.nextTick(function(doprocess(segment1); process.nextTick(function(){doprocess(segment2)

每个doProcess调用下一个doProcess

节点js将在请求之间交换时间。

现在采用该解决方案并将其扩展为每个服务器4个节点实例和2-5个服务器

突然间你有一个极具规模和成本效益的解决方案。