subprocess的CPU密集型任务?

所以我开始为我正在做的一个项目使用node.js。

当客户端发出请求时,我的node.js服务器从另一个服务器获取一个json,然后将其重新格式化为一个新的json,并将其传递给这个客户端。 然而,节点服务器从其他服务器获得的json可能会相当大,因此对数据的“按摩”相当密集。

过去几个小时我一直在阅读node.js是不是很好的CPU任务和我见过的主要反应是产生一个subprocess(基本上是一个.js文件运行通过不同的节点实例)处理任何可能阻塞主事件循环的cpu密集型任务。

假设我拥有20,000个并发用户,这意味着它将运行这些subprocess,产生20000个os级别的作业。

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

我不确定是否应该运行一个subprocess。 但是我需要做一个非阻塞的cpu密集型任务。 任何想法我应该做什么?

与 许多 服务器端语言 相比 ,支持Node的V8 Javascript引擎实际上相当快 。

问题是Node的Evented Model与协作式多任务非常相似 – 一个特定的请求操作将会继续,直到它把控制权交还给Javascript事件循环,所以高CPU任务将阻止循环(这意味着随机select的用户会得到完美的性能和另一个组将获得超时,而不是性能退化与负载)。

因此,对于CPU密集型任务,您可以使用以下几种解决scheme:

  1. 你可以像处理pipe道一样处理你的代码,并简单地在显着的处理块之间处理process.nextTick ,以减less平均延迟(同时增加绝对最小值),基本上更“协作”,不会让任何一个请求支配CPU长时间。
  2. 如果您的工作是纯Javascript(不需要Node模块),则可以使用node-webworker-threads库将CPU密集型工作卸载到线程。 然而,不断产生新的线程可能是一个坏主意,所以你可能需要一个线程池,你排队工作,这些工人拉回发送和输出队列。 在这种情况下…
  3. 您创build一个subprocess工作者池,并使用相同的排队机制,其中池大小取决于需要CPU密集型path的请求的百分比,请求的总数以及这些请求允许的容许延迟增加。

那些说不懂如何构build解决scheme的人。

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

在你的例子中,你的节点实例连接到一个外部API,并抓住JSON来处理和发回。

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

所以你会怎么做? 问自己是时间问题? 如果是这样,那么节点不是解决scheme然而,如果你对原始处理能力更感兴趣,而不是在4秒内完成1个请求

你有兴趣在10秒内完成200个请求,但每个人需要约10秒。

诊断你的JSON需要多长时间按摩,如果不到1秒。 只需运行4个节点实例而不是1个。

但是,如果它比这更复杂,请将json分割成若干段进行处理。 并使用asynchronouscallback来处理每个段

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

每个doProcess调用下一个doProcess

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

现在,采取该解决scheme,并将其扩展到每个服务器4个节点实例,以及2-5个服务器

突然之间你有一个非常可扩展和成本效益的解决scheme。