Node.js真的有高并发优势吗

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Node.js真的有高并发优势吗相关的知识,希望对你有一定的参考价值。

参考技术A 如果都是只有一个线程的话,node.js这些东西会有高并发的优势。如果普通的程序用多进程/多线程并且配置的合适的话,其实是差不多的。 所以这一方面node.js真正的优势不是高并发,而是容易配置,有几个处理器核心就运行几个进程,这样就可以把计算能力完全发挥出来。而不用像普通的程序那样,配置运行几个进程几个线程,设多了怕浪费资源,设少了又怕浪费cpu能力。

nodejs每秒并发多高

脱离带宽内存与计算量来讨论并发是没有意义的。

因为并发数受带宽及其它很多因素影响,不能单就node.js来说并发多高。

如果无限带宽,无限计算力,无限存……你可以认为node.js并发数也是无限的,但这没有意义,在同样的情况下,就算是IIS,并发数也可以认为是无限的。

node.js的优势严格来说不是并发而是“非阻塞”。

它是通过非阻塞来达到高并发的目标的,我们用node.js也是用它的非阻塞这个特点。

在优化线程池,以及端口复用等技术的基础上,对于简单的业务处,使用其它的模型也可以达到高并发的目标,但在面临业务逻辑耗时长的问题时,node.js的优势就比较明显。

如果一个事务请求涉及三个业务逻辑,比如登录(login)这个事务,假设我们定义它有三个业务逻辑:

    verify:验证用户是否合法(用户名,密码什么的);

    user:获取身份信息(权限什么的);

    modules:返回他可用的业务接口列表(商品管理,用户管理,订单审核等)

我们假设:只有1完成了才可以进行2,2完成了才可以进行3,上述每个业务逻辑都需要1秒去完成(客户的登录请求这个事务需要3秒才能完成)。

同时,我们也假设,这三个业务逻辑服务都是在其它的服务器上,它们的并发数无上限。

然后,我们在“一瞬间”我向这个服务发出1000个login请求

那么,我们来看看node.js与纯java的不同。

nodejs调用它们来完成,因为它是非阻塞的,它调了verify后,不再等待它返回结果,就可以处理另一个事务请求了,当verify请求有返回结果时,它再来处理结果,决定是否调用user……,整个过程,只在一个进程中就完成了。

它收到这1000个请求后,在这个进程中向verify发出了1000个请求,过了一秒,收到回应又有900个验证成功,它返回了100个登录失败的信息,并向user发出了900个请求,又过了一秒,返回了900个modules的结果。

这样的结果,在客户端看来,发出请求后1秒,收到了100个登录失败,又过了两秒,收到了900个可用功能列表(因为异步机制,它还会稍微长一点点,假设是3.003秒吧)

现在,在带宽与计算力不受限的情况下,同样的内存,看看纯Java是怎么个情况。如果使用纯java来做这个事,java不使用异步模式的话,一个线程响应一个请求。

java同样“一瞬间”收到了1000个请求,java开启了1000个线程去响应它们,然后这1000个线程在第一秒里都在等待verify,第一秒结束时,返回100个登录失败,关闭了100个线程,又过了两秒,900个线程得到了各自的modules结果,并返回给客户端。

对于客户端来说,感觉就是3秒,没有那个0.003。

好,至此,node.js与纯java的区别已经很明显了。纯java在不使用非阻塞机制的情况下,它需要开启1000个线程(或者进程,这个成本更高)而node.js则需要更多的时间。

在内存受限的情况下,node.js就有优势了。

假设一个进程需要1M内存,为了能同时开1000进程,你需要额外的1G内存来给它。而对于node.js,它可能只需要20M来完成这个事,代价就是每个客户端都需要多等那么一小会。

严格来说,并不提倡在node.js中实现业务逻辑,node.js最好是只用于以非阻塞模式连接多个阻塞模式的业务逻辑

参考技术A 同一套业务逻辑,实现一个webservice中间接口,中间涉及memcached和mogodb的一些操作。
分别在Node.js和JAVA平台实现,java代码部署在Tomcat 7.0上,用Apache jmeter进行压力测试。
得到的测试结果很是出乎意料,Node.js的高并发优势为什么没有体现出来呢???
**操作系统:**CentOS 6.4(虚拟机)
**内存:**1.5G
**CPU:**单核
并发数 100
**ramp-up period(in seconds)**1执行次数 10
以下是测试结果:Lable #Sample Average Median 90%Line Min Max Error% Throughput KB/secNode.js HTTP请求 1000 333 369 485 1 956 0.0 183.3180568285976 40.995932630614114
Tomcat HTTP请求 1000 48 9 188 2 563 0.0 183.4862385321101 58.414564220183486
可以看到Node.js的平均执行时间为333毫秒,Tomcat的执行时间为48毫秒,Tomcat比Node.js快了近7倍!
补充1:即使是测试接口直接返回,不涉及后续的操作,Tomcat也比Node.js快了很多,求各位大神给个解释。
补充2:修改jmeter 的 ramp-up period的测试条件,比如这个值增大(如10秒),node.js的执行效率变高了,但这么想来也是违背了高并发的特性
抛砖引玉,一起探讨问题。如果你也感兴趣,不妨拿出点时间来写一段程序测试一下,我希望能得到不一样的结果。

以上是关于Node.js真的有高并发优势吗的主要内容,如果未能解决你的问题,请参考以下文章

node.js浅见

redisproxy有高并发限制吗

刷了这份“阿里亿级高并发系统设计学习笔记”,你会觉得之前刷过的都是渣渣!

没有高并发项目经验,但经常被问高并发性能调优问题怎么办?

《重学Java高并发》你管这“破玩意儿”叫锁(没有高并发经验的朋友们看过来,该专栏结合笔者的实战来讲高并发)

《重学Java高并发》你管这“破玩意儿”叫锁(没有高并发经验的朋友们看过来,该专栏结合笔者的实战来讲高并发)