【问题标题】：How to configure Nginx with Passenger to process 500 requests/sec如何使用Passenger配置Nginx以处理500个请求/秒
【发布时间】：2017-07-04 22:38:46
【问题描述】：

我正在托管 ruby 应用程序，但它在每秒处理超过 400 个请求时会出现错误（某种错误 500）。请求数量较少（低于 400 个请求）的测试（loader.io）以良好的结果结束。我认为我可以在每秒处理 500 个请求甚至更多时获得更好的结果。

该应用正在使用 t2.2xlarge ec2 实例（具有 32Gb 内存，8 个虚拟内核）。我想它可能会提供更好的性能。该机器运行在 Ubuntu 14.04、Rails 4.0.12、Nginx with Passenger 上。

我尝试对 Nginx 配置进行一些更改，但没有任何大的进展。我目前的配置：

passenger_max_pool_size 60;
#passenger_pool_idle_time 20;
server {
  listen 80;
  return 301 https://mydomain.eu$request_uri;
}

server {
  listen 443;
  server_name ~^(\w+)\.mydomain.eu$;
  return 301 https://mydomain.eu$request_uri;
}
server {
  listen 443 ssl spdy default;
  server_name mydomain.eu;
  passenger_enabled on;
  #passenger_max_pool_size 12;
  passenger_max_request_queue_size 2000;
  gzip on;

  root /home/ubuntu/application/cversion/public;

  ssl                  on;
  ssl_certificate      /home/ubuntu/fvhsdvhfd35/ssl-bundle1.crt;
  ssl_certificate_key  /home/ubuntu/fvhsdvhfd35/prvt.key;
  ssl_session_timeout  5m;
  ssl_protocols        TLSv1 TLSv1.1 TLSv1.2 SSLv3;
  ssl_ciphers          "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
  ssl_prefer_server_ciphers  on;

  location = /favicon.png {
    expires    max;
    add_header Cache-Control public;
  }

  location = /ZeroClipboard.swf {
    expires    max;
    add_header Cache-Control public;
  }

  location ~ ^/(assets)/  {
    gzip_static on;
    expires     max;
    add_header  Cache-Control public;
  }

  # disable gzip on all omniauth paths to prevent BREACH
  location ~ ^/auth/ {
    gzip off;
    passenger_enabled on;
  }

你知道如何每秒获得超过 400 个请求吗？

这是处理 500 个请求时带有乘客的 Nginx 日志（passenger_max_pool_size 30; 和 passenger_max_request_queue_size 1200;）

2017/07/06 01:58:32 [error] 11749#11749: *56391 connect() to unix:/tmp/passenger.e1PiPXp/agents.s/core failed (11: Resource temporarily unavailable) while connecting to upstream, client: 54.89.44.6, server: mydomain.us, request: "GET / HTTP/1.1", upstream: "passenger:unix:/tmp/passenger.e1PiPXp/agents.s/core:", host: "mydomain.us"
2017/07/06 01:58:32 [error] 11740#11740: *64104 connect() to unix:/tmp/passenger.e1PiPXp/agents.s/core failed (11: Resource temporarily unavailable) while connecting to upstream, client: 52.87.219.148, server: mydomain.us, request: "GET / HTTP/1.1", upstream: "passenger:unix:/tmp/passenger.e1PiPXp/agents.s/core:", host: "mydomain.us"
2017/07/06 01:58:32 [error] 11749#11749: *64251 connect() to unix:/tmp/passenger.e1PiPXp/agents.s/core failed (11: Resource temporarily unavailable) while connecting to upstream, client: 52.87.219.148, server: mydomain.us, request: "GET / HTTP/1.1", upstream: "passenger:unix:/tmp/passenger.e1PiPXp/agents.s/core:", host: "mydomain.us"
2017/07/06 01:58:32 [error] 11749#11749: *63289 connect() to unix:/tmp/passenger.e1PiPXp/agents.s/core failed (11: Resource temporarily unavailable) while connecting to upstream, client: 54.89.44.6, server: mydomain.us, request: "GET / HTTP/1.1", upstream: "passenger:unix:/tmp/passenger.e1PiPXp/agents.s/core:", host: "mydomain.us"
2017/07/06 01:58:32 [error] 11748#11748: *67786 connect() to unix:/tmp/passenger.e1PiPXp/agents.s/core failed (11: Resource temporarily unavailable) while connecting to upstream, client: 52.86.198.91, server: mydomain.us, request: "GET / HTTP/1.1", upstream: "passenger:unix:/tmp/passenger.e1PiPXp/agents.s/core:", host: "mydomain.us"
2017/07/06 01:58:32 [error] 11748#11748: *35057 connect() to unix:/tmp/passenger.e1PiPXp/agents.s/core failed (11: Resource temporarily unavailable) while connecting to upstream, client: 52.86.198.91, server: mydomain.us, request: "GET / HTTP/1.1", upstream: "passenger:unix:/tmp/passenger.e1PiPXp/agents.s/core:", host: "mydomain.us"
2017/07/06 01:58:32 [error] 11748#11748: *35166 connect() to unix:/tmp/passenger.e1PiPXp/agents.s/core failed (11: Resource temporarily unavailable) while connecting to upstream, client: 52.86.198.91, server: mydomain.us, request: "GET / HTTP/1.1", upstream: "passenger:unix:/tmp/passenger.e1PiPXp/agents.s/core:", host: "mydomain.us"
2017/07/06 01:58:32 [error] 11744#11744: *43208 connect() to unix:/tmp/passenger.e1PiPXp/agents.s/core failed (11: Resource temporarily unavailable) while connecting to upstream, client: 52.86.198.91, server: mydomain.us, request: "GET / HTTP/1.1", upstream: "passenger:unix:/tmp/passenger.e1PiPXp/agents.s/core:", host: "mydomain.us"
2017/07/06 01:58:32 [error] 11744#11744: *69130 connect() to unix:/tmp/passenger.e1PiPXp/agents.s/core failed (11: Resource temporarily unavailable) while connecting to upstream, client: 54.162.105.71, server: mydomain.us, request: "GET / HTTP/1.1", upstream: "passenger:unix:/tmp/passenger.e1PiPXp/agents.s/core:", host: "mydomain.us"
[ 2017-07-06 01:58:34.3865 11703/7fc703fff700 Ser/AcceptLoadBalancer.h:150 ]: Resuming accepting new clients

更新

我有一个解决方案。 Nginx 配置的这些更改给了我 1000 请求/秒的性能。

起初我说：

"65536" in /proc/sys/net/core/somaxconn
"65536" in /proc/sys/net/ipv4/tcp_max_syn_backlog

/etc/nginx/conf.d/m.conf:

    passenger_max_pool_size 90;
    passenger_socket_backlog 16384;

    #in server block
    #was listen 443 ssl spdy default;
    listen 443 ssl spdy default backlog=16384;
    passenger_max_request_queue_size 2300;
    ssl_session_cache shared:SSL:10m;

/etc/nginx/nginx.conf:

worker_rlimit_nofile 131072;

#in events block:
use epoll;
worker_connections 8192;

另一个问题

在 1 分钟的测试期间，每秒 1000 个请求的平均响应时间约为 6 秒。有什么想法可以改善这种请求数量的平均响应时间吗？

更新2

我根据this 博客更改了我的 Nginx 配置以启用 Nginx Microcashing，但我没有更好的性能。 500 req/second 给了我 5.1 秒的平均响应时间。大约 900 个请求/秒 - 5.5 秒。但是，如果没有缓存，500 个请求需要 2.5 秒，900 个请求需要 5.6 秒。

/etc/nginx/nginx.conf:

    ...
    http {
      ...
      proxy_cache_path /tmp/cache keys_zone=one:10m levels=1:2 inactive=600s max_size=100m;
      ...
    }

/etc/nginx/conf.d/m.conf:

}

passenger_max_pool_size 90;
#passenger_pool_idle_time 20;
passenger_socket_backlog 16384;
server {
  listen 80;
  return 301 https://mydomain.eu$request_uri;
}

server {
  listen 443;
  server_name ~^(\w+)\.mydomain.eu$;
  return 301 https://mydomain.eu$request_uri;
}
server {
  listen 443 ssl spdy default backlog=16384;
  server_name mydomain.eu;

  ssl                  on;
  ssl_certificate      /home/ubuntu/fvhsdvhfd35/ssl-bundle1.crt;
  ssl_certificate_key  /home/ubuntu/fvhsdvhfd35/prvt.key;
  ssl_session_timeout  5m;
  ssl_protocols        TLSv1 TLSv1.1 TLSv1.2 SSLv3;
  ssl_ciphers          "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
  ssl_prefer_server_ciphers  on;

  ssl_session_cache shared:SSL:10m;

  location / {

    proxy_http_version 1.1; # Always upgrade to HTTP/1.1
    proxy_set_header Connection ""; # Enable keepalives
    proxy_set_header Accept-Encoding ""; # Optimize encoding
    proxy_pass http://127.0.0.1:81/;

    proxy_cache one;
    proxy_cache_lock on;
    proxy_cache_valid 200 1s;
    proxy_cache_use_stale updating;
  }
}
server {

  listen 81;
  server_name mydomain.eu;
  passenger_enabled on;

  passenger_max_request_queue_size 2300;
  gzip on;

  root /home/ubuntu/application/cversion/public;


  location = /favicon.png {
    expires    max;
    add_header Cache-Control public;
  }

  location = /ZeroClipboard.swf {
    expires    max;
    add_header Cache-Control public;
  }

  location ~ ^/(assets)/  {
    gzip_static on;
    expires     max;
    add_header  Cache-Control public;
  }

  # disable gzip on all omniauth paths to prevent BREACH
  location ~ ^/auth/ {
    gzip off;
    passenger_enabled on;
  }

}

【问题讨论】：

这个问题非常广泛，您可以考虑添加更多详细信息，例如来自 EC2 的 Rails 应用程序日志和统计信息，例如内存、磁盘 I/O 等。在描述中我看到了一个基本的错误配置（从性能点观点）此类基于 CPU 积分运行的 t2.* 类型实例，请参阅stackoverflow.com/questions/28984106/… 了解更多详细信息
Nginx 日志中有什么？
好的，鉴于现在基于Passenger documentation 的 Nginx 错误详细信息，我会尝试增加工作连接的数量：events { worker_connections 4096; }
为了减少 CPU 消耗以处理不可预测的 CPU 性能，可以使用 ssl_session_cache: ssl_session_cache shared:SSL:10m;
好吧，没有足够的细节：相同的错误没有帮助，不可能完全相同。每次进行性能和负载测试时，都有详细的日志（Nginx 和应用程序）是解决问题的关键。在我们看到更多数据（例如 Nginx 版本、其完整配置、在测试之间重新启动 Nginx 的证据、Rails 应用程序日志、确切的错误等）之前，没有必要推测可能导致问题的原因，而不仅仅是 某种 500.

标签： ruby-on-rails nginx amazon passenger

【解决方案1】：

为了进行这些优化，请确保您参考链接 nginx blog 并考虑每个请求的响应时间（尽可能使用 Rails 技术将其最小化）。还要考虑您的数据库优化，即同时使用正确的索引和最大数据库连接数。因为这是一个多层次的问题，必须在每个层次上进行配置以获得最佳性能。祝你好运:)

【讨论】：

感谢您的建议。我是 Rails 的新手。您能详细介绍一下 Rails 技术吗？
你可以查看query caching 并考虑使用缓存视图。你是否在超过 500 rps 时获得 503。当您测试 500rps 时，您是否使用 newrelic 检查您的应用程序/数据库中是否存在导致问题的瓶颈。

【解决方案2】：

Nginx 配置可根据官方性能调优建议查看：https://www.nginx.com/blog/tuning-nginx/

【讨论】：

Nginx 每秒可以处理数千个请求，您建议考虑调整什么，在这种情况下 Nginx 配置是瓶颈吗？
如果您正在寻找优化的配置，那么这里是 linode.com/docs/web-servers/nginx/… 否则请按照文档并尝试做所有设置的时间。