nodejs每秒并发多高

Posted 2023-03-09

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

因为并发数受带宽及其它很多因素影响，不能单就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的执行效率变高了，但这么想来也是违背了高并发的特性
抛砖引玉，一起探讨问题。如果你也感兴趣，不妨拿出点时间来写一段程序测试一下，我希望能得到不一样的结果。