worker_threads 稳定了,egg 不考虑弄个线程池?
发布于 3 个月前 作者 mzTeamMeatMan 2360 次浏览 来自 问答

我发现,启动一个 worker_threads 需要花费 1 - 2 秒,如果作为中间层服务并不太实际,可以如果做成线程池,预启动好 max 数量的线程,通过事件来执行线程里的东西,这样会不会很快速呢?

目前用的是 egg , 如果跟 master 进程管理的模式,保证线程池数量,挂一个启动一个,然后再加一个 workerPool 层?

14 回复
  • 进程又不是根据请求来动态 fork 的,而是启动期就启动好的,启动耗时对用户请求耗时是没有影响的。
  • 99% 的耗时在你的业务逻辑代码上,譬如一个 sync 之类的。

别用java 的思想解决node.js 的问题~ 另外,worker_threads 对IO 密集型应用提升有限,增加了复杂度,甚至降低性能 (单线程没有线程切换的损耗) 对于8核以上,你开多实例即可

@zuohuadong 可有根据?还是仅仅猜测。

重 CPU 的操作也不应该在 Web 服务器上去做,应该丢到 函数计算 这类的服务去

@zy445566 你自己实际压测下就明白了, IO 密集(读数据库)的一个接口,4核心机器测试下来 单线程并发高10%左右。 瓶颈压根不在这。

paypal 之前也有测试数据 对比 node.js 单核 4G ,java 四核8G ,node.js 并发还比 java 高一倍。

除非你是做算法或者其他CPU密集型业务,不然多线程的必要性不大

@zuohuadong 之前看错了,看成CUP密集型了

worker_threads 对于 IO密集场景意义不大, CPU 场景有一定提升

@atian25 这个我知道呀,有一些运算的需要放到多线程去做,我期望的是可以有个线程池可以来完成我的任务

@zuohuadong 可就是会有运算的需求呢,而且没有 java 呢,现在 web 和系统都是一体,如果说 java 的思想,那么定时器算不算也是 java 的思想?

@atian25 作为一个强微信业务的公司来说,是没有那么多服务器的,基本都是全干,也不区分 web i/o 类需求还是函数计算需求

@mzTeamMeatMan 微信也有对应的函数计算啊,这种重操作就应该用函数计算,整体费用会便宜很多的。

全干不等于你所有的东西都用一个东西来干。

可以参考下 语雀 他们的实践:“云”端的语雀:用 JavaScript 全栈打造商业级应用

@mzTeamMeatMan 定时器很多语言都有,node.js 也有类似的实现和包。 如果运算需求是瓶颈的话,运算这块用C++ 写,封装成拓展,node.js 来调用。

如果是微信业务,那就有意思了,那都不叫运算需求了。

数据分析、图像处理、AI、针对特殊场景的算法… 你看看你用到了哪一个?

不要为1%的计算需求,花99% 的时间考虑。

有少量的计算,就专门开个服务偶尔跑一下,跟业务隔离开。

如果你的业务能用 java ,js 这些来做计算,那都不叫CPU 密集型。 别闹了 建议你还是先放到实际环境里运行就明白了,而不是颅内运行。

@mzTeamMeatMan 还是要拆一下的。因为你不知道什么时候eventloop里有一个阻塞任务。于是所有机器可能都挂了。

基于事件,在eventloop底层已有线程池实现了,不必再折腾

worker_threads 本身就不是和其他语言中的“线程”相同,javaScript本身就永远不可能拥有“多线程”,因为这样所以首先用起来概念上会比较“畸形”,你看看官方的第一个demo,那和普通语言下的“线程”这种概念相差甚远,那就是轻量级的能够直接共享内存对象进行通讯的“process”,放进框架里面我会觉得头晕(因为想不到要怎么做,要做成怎么样,做好了对大部分需求是否能“通用”),接着,还不知道这“process”的消耗如何。所以碰到类似情况,是我的话,要不就自己写worker_threads服务,要不就其他服务解决。倒是对worker_threads的一些使用封装会比较感兴趣。

回到顶部