nginx反向代理性能瓶颈的根本原因是什么？

Question

我们运行 nginx 作为具有 TLS 终止功能的反向代理。

我们最近错误地将一台 4 核机器换成了一台 1 核机器，并注意到在负载下我们的“请求排队”指标急剧上升（从正常的约 10 毫秒上升到平均约 10 秒）。当我们意识到大小错误并升级到 4 核时，问题就消失了，但我想确切了解导致速度变慢的原因，以便我们能够知道将来随着流量增加我们是否会遇到类似的情况。

“请求排队”指标只是计算 nginx 代理添加到代理请求的时间戳（X-Request-Start）与我们的应用程序在后端 Web 服务器上处理该请求的时间之间的差值。

此值通常表示我们的后端服务器上有排队，因为后端 Web 服务器内置有明确的请求排队机制。在本例中，后端服务器上没有任何排队。

我们的worker_connections/worker_processes配置是：

worker_processes auto;
worker_rlimit_nofile 20000;

events {
  worker_connections 10000;
}

当时的观察：

• $request_timenginx 访问日志中显示的数字在正常范围内（平均约 100 毫秒）
• 系统指标显示，平均 CPU 利用率稳定在 60%
• nginx 的 stub_status 报告的活动连接数约为 6k，升级后上升到 10k 左右

在 nginx 内部，这种延迟从何而来，技术解释是什么？似乎发生在接受连接并添加标头之后，但在请求到达后端之前。我如何监控它，我可以计算在 4 个核心上我们可能在什么级别的流量下再次遇到它吗？

Nginx 配置（我认为相关的部分...）：

user www-data;
worker_processes auto;
worker_rlimit_nofile 20000;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
  worker_connections 10000;
}

http {
  log_format upstreamlog '[$time_local] $remote_addr - $remote_user - $host  to: $upstream_addr: $request upstream_response_time $upstream_response_time msec $msec request_time $request_time status $status sent_bytes $bytes_sent';

  upstream app_backend {
    least_conn;
    server 100.64.32.11:8080; # app01
    server 100.64.32.41:8080; # app02
    # ... etc ...
  }

  server {
    listen 80;
    listen [::]:80;
    server_name ~^[^\.]+\.app\.net$;

    return 301 https://$host$request_uri;
  }

  server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name ~^[^\.]+\.app\.net$;

    ssl_certificate /etc/nginx/ssl/app.crt;
    ssl_certificate_key /etc/nginx/ssl/app.key;

    location / {
      proxy_pass            http://app_backend;
      proxy_set_header      Host $host;
      proxy_set_header      X-Real-IP $remote_addr;
      proxy_set_header      X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header      X-Forwarded-Proto $scheme;
      proxy_set_header      X-Request-Start "t=${msec}";
      access_log            /var/log/nginx/access.log upstreamlog;
      proxy_send_timeout    300;
      proxy_read_timeout    300;
    }
  }
}