為什么在Nginx中增加worker_connections會使node.js集群中的應用程序變慢？

Question

我正在將我的應用程序轉換為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
}

這是我的Nginx配置。

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

我在Nginx服務器上有2個CPU。

這是我之前的表現。

我得到1,500請求/ s，這是非常好的。 現在我想我會增加Nginx上的連接數，這樣我就可以接受更多的請求了。 我這樣做

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

這是我的表演后。

我認為這比以前更糟糕。

我使用gatling進行性能測試，這是代碼。

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集群。 所以，我有3個EC2實例在30秒內向我的應用程序發出15,000個請求。

問題是，有什么辦法可以提高我的應用程序性能，或者我只需要添加更多的機器？

我正在測試的路線非常簡單，我收到請求並將其發送到RabbitMQ，以便進一步處理。 所以，那條路線的反應非常快。

Answer 1

您已經提到過您正在使用AWS並在ELB中的EC2實例前面。 我看到你得到502和503狀態代碼。 這些可以從ELB或您的EC2實例發送。 確保在進行負載測試時，您知道錯誤來自何處。 您可以在AWS控制台中使用ELB CloudWatch指標進行檢查 。

基本上HTTPCode_ELB_5XX意味着您的ELB發送了50x。 另一方面HTTPCode_Backend_5XX發送50x。 您還可以在ELB的日志中驗證。 你可以在這里找到對ELB錯誤的更好解釋。

要在AWS上進行負載測試，您一定要閱讀此內容 。 重點是ELB只是另一組機器，如果負載增加需要擴展。 默認縮放策略是（引用“Ramping Up Testing”一節）：

一旦有了測試工具，就需要定義負載的增長。 我們建議您每五分鍾以不超過50％的速度增加負載。

這意味着當您從一些並發用戶開始時，假設1000，默認情況下，您應該在5分鍾內最多增加1500。 這將保證ELB隨着服務器的負載而擴展。 確切的數字可能會有所不同，您必須自己測試它們。 上次我測試了1200 req./sw/o的持續負載問題，然后我開始接收50x。 您可以從單個客戶端輕松地從X到Y用戶運行加速場景並等待50x。

下一個非常重要的事情（從“DNS Resoultion”部分）是：

如果客戶端每分鍾至少重新解析一次DNS，則客戶端將不會使用Elastic Load Balancing添加到DNS的新資源。

簡而言之，這意味着您必須保證DNS中的TTL得到尊重，或者您的客戶端通過執行DNS查找來重新解析並輪換他們收到的DNS IP，以保證循環方式以分配負載。 如果不是（例如，僅從一個客戶端進行測試，而不是您的情況），您可以通過將所有流量僅定位到一個實例來重載ELB實例來扭曲結果。 這意味着ELB根本不會擴展。

希望它會有所幫助。