为什么在Nginx中增加worker_connections使node.js集群中的应用程序变得更慢?

我正在将我的应用程序转换为node.js集群,我希望这会提高我的应用程序的性能

目前,我正在将应用程序部署到2个EC2 t2.medium实例。 我有Nginx作为代理和ELB。

这是我的快速集群应用程序,这是相当标准的文档。

var bodyParser = require('body-parser'); var cors = require('cors'); var cluster = require('cluster'); var debug = require('debug')('expressapp'); if(cluster.isMaster) { var numWorkers = require('os').cpus().length; debug('Master cluster setting up ' + numWorkers + ' workers'); for(var i = 0; i < numWorkers; i++) { cluster.fork(); } cluster.on('online', function(worker) { debug('Worker ' + worker.process.pid + ' is online'); }); cluster.on('exit', function(worker, code, signal) { debug('Worker ' + worker.process.pid + ' died with code: ' + code + ', and signal: ' + signal); debug('Starting a new worker'); cluster.fork(); }); } else { // Express stuff } 

这是我的Nginxconfiguration。

 nginx::worker_processes: "%{::processorcount}" nginx::worker_connections: '1024' nginx::keepalive_timeout: '65' 

我在Nginx服务器上有2个CPU。

这是我以前的表演。

在这里输入图像说明

我得到1500个相当不错的请求。 现在我想我会增加Nginx的连接数量,所以我可以接受更多的请求。 我这样做

 nginx::worker_processes: "%{::processorcount}" nginx::worker_connections: '2048' nginx::keepalive_timeout: '65' 

这是我的表演后。

在这里输入图像说明

我认为这比以前更糟糕。

我使用gatling进行性能testing,这里是代码。

 import io.gatling.core.Predef._ import io.gatling.http.Predef._ import scala.concurrent.duration._ class LoadTestSparrowCapture extends Simulation { val httpConf = http .baseURL("http://ELB") .acceptHeader("application/json") .doNotTrackHeader("1") .acceptLanguageHeader("en-US,en;q=0.5") .acceptEncodingHeader("gzip, defalt") .userAgentHeader("Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20100101 Firefox/16.0") val headers_10 = Map("Content-Type" -> "application/json") val scn = scenario("Load Test") .exec(http("request_1") .get("/track")) setUp( scn.inject( atOnceUsers(15000) ).protocols(httpConf)) } 

我把它部署到我的gatling集群。 所以,我有三个EC2实例在30秒内向我的应用程序发出了15000个请求。

问题是,有什么我可以做,以提高我的应用程序的性能,或者我只需要添加更多的机器?

我正在testing的路由非常简单,我得到请求并将其发送到RabbitMQ,以便进一步处理。 所以,这条路线的反应是相当快的。

你已经提到你正在使用AWS,并且在ELB的EC2实例的前面。 正如我看到你得到502和503状态代码。 这些可以从ELB或您的EC2实例发送。 确保在进行负载测试时您知道错误来自哪里。 您可以在ELB CloudWatch指标的 AWS控制台中进行检查。

基本上HTTPCode_ELB_5XX表示你的ELB发送50x。 另一方面HTTPCode_Backend_5XX发送50x。 您也可以在ELB的日志中验证。 更好地解释ELB的错误,你可以在这里找到。

要在AWS上进行加载测试,您一定要阅读。 要点是,ELB只是另一套机器,如果你的负载增加,需要扩展。 默认缩放策略(引自“加速测试”部分):

一旦你有一个测试工具,你将需要定义负载的增长。 我们建议您每五分钟以不超过50%的速度增加负载。

这意味着当你从一些并发用户开始时,比如说1000,在默认情况下,你应该在5分钟内只增加1500。 这将保证ELB在您的服务器上负载均衡。 确切的数字可能会有所不同,你必须自己测试。 上次我已经测试了1200个req​​./sw/o的持续负载问题,然后我开始收到50x。 您可以轻松测试,从单个客户端的X到Y用户运行渐增方案,并等待50倍。

其次非常重要的一点(从“DNS Resoultion”部分)是:

如果客户端每分钟至少不重新解析一次DNS,则Elastic Load Balancing添加到DNS的新资源将不会被客户端使用。

简而言之,这意味着您必须保证DNS中的TTL得到尊重,或者您的客户端通过DNS查找重新解析和旋转他们所接收的DNS IP,以保证循环方式来分配负载。 如果不是(例如仅从一个客户端进行测试,而不是您的情况),则可以通过将所有流量仅定向到一个实例来重载ELB的一个实例来歪曲结果。 这意味着ELB根本不会扩展。

希望它会有所帮助。