nginx和uwsgi：上游响应时间和请求时间相差很大

Question

免责声明：这在技术上与学校项目有关，但我已经和我的教授谈过了，他也对此感到困惑。

我有一个 nginx 负载均衡器反向代理到几个 uwsgi + flask 应用程序。这些应用程序旨在处理非常高的吞吐量/负载。我从 uwsgi 得到的响应时间非常好，而且 nginx 服务器的 CPU 使用率和平均负载都很低，但总体请求时间非常长。

我已经研究过这个问题，我发现的所有线程都说这总是由客户端连接速度慢引起的。但是，请求是由同一网络上的脚本发出的，这个问题不会影响其他人的设置，所以在我看来，这是我的 nginx 配置的问题。不过这让我感到非常困惑，因为 nginx 成为这样的瓶颈似乎几乎闻所未闻。

为了了解问题的严重程度，有三种主要的请求类型：添加图片、搜索和添加推文（它是推特克隆）。

对于添加图片，总体请求时间平均比上游响应时间长约 20 倍。对于搜索，它是 3 倍，并添加推文 1.5。我对这里不同之处的理论是，添加图像的数据量比搜索或添加推文要大得多，而搜索比添加推文要大得多。

我的 nginx.conf 是：

user www-data;
pid /run/nginx.pid;

worker_processes auto;
worker_rlimit_nofile 30000;
events { 
    worker_connections 30000; 
}

http { 
    # Settings.
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    client_body_buffer_size 200K;
    keepalive_timeout 65;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # SSL.
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;

    # Logging
    log_format req_time '$remote_addr - $remote_user [$time_local] '
                         'REQUEST: $request '
                 'STATUS: $status '
                 'BACK_END: $upstream_addr '
                 'UPSTREAM_TIME: $upstream_response_time s '
                 'REQ_TIME: $request_time s ';
                 'CONNECT_TIME: $upstream_connect_time s';
    error_log  /var/log/nginx/error.log;
    access_log /var/log/nginx/access.log req_time;


    # GZIP business
    gzip on;
    gzip_disable "msie6";

    # Routing.
    upstream media {
        server 192.168.1.91:5000;
    }

    upstream search {
        least_conn;
        server 192.168.1.84:5000;
        server 192.168.1.134:5000;
    }

    upstream uwsgi_app {
        least_conn;
        server 192.168.1.85:5000;
        server 192.168.1.89:5000;
        server 192.168.1.82:5000;
        server 192.168.1.125:5000;
        server 192.168.1.86:5000;
        server 192.168.1.122:5000;
        server 192.168.1.128:5000;
        server 192.168.1.131:5000;
        server 192.168.1.137:5000;    
    }

    server {
        listen 80;
        server_name localhost;

        location /addmedia {
            include uwsgi_params;
        uwsgi_read_timeout 5s;
        proxy_read_timeout 5s;
            uwsgi_pass media;
        }

        location /media {
            include uwsgi_params;
        uwsgi_read_timeout 5s;
        proxy_read_timeout 5s;
            uwsgi_pass media;
        } 

        location /search {
            include uwsgi_params;
        uwsgi_read_timeout 5s;
        proxy_read_timeout 5s;
            uwsgi_pass search;
        }

        location /time-search {
            rewrite /time-search(.*) /times break;
                        include uwsgi_params;
                        uwsgi_pass search;
        }

        location /item {
            include uwsgi_params;
        uwsgi_read_timeout 5s;
        proxy_read_timeout 5s;
            if ($request_method = DELETE) {
                uwsgi_pass media;
            }

            if ($request_method = GET) {
                uwsgi_pass uwsgi_app;
            }

            if ($request_method = POST) {
                uwsgi_pass uwsgi_app;
            }
        }

        location / {
            include uwsgi_params;
        uwsgi_read_timeout 5s;
        proxy_read_timeout 5s;
            uwsgi_pass uwsgi_app;
        }
    }
}

而我的 uwsgi ini 是：

[uwsgi]
chdir = /home/ubuntu/app/
module = app
callable = app
master = true
processes = 25
socket = 0.0.0.0:5000
socket-timeout = 5
die-on-term = true
home = /home/ubuntu/app/venv/
uid = 1000
buffer-size=65535
single-interpreter = true

任何有关此问题原因的见解将不胜感激。

Answer 1

所以，我想我想通了。从阅读 nginx 文档 (https://www.nginx.com/blog/using-nginx-logging-for-application-performance-monitoring/) 看来，需要注意三个指标：upstream_response_time、request_time 和 upstream_connect_time。我专注于 upstream_response_time 和 request_time 之间的区别。

然而，upstream_response_time 是上游接受请求和返回响应之间的时间。它不包括 upstream_connect 时间，或与上游服务器建立连接所需的时间。而在 uwsgi 的上下文中，这非常重要，因为如果没有工作人员可以接受请求，则该请求将被积压。我认为请求等待积压的时间可能算作 upstream_connect_time，而不是 nginx 中的 upstream_response_time，因为 uwsgi 还没有读取任何字节。

不幸的是，我不能 100% 确定，因为我在记录 upstream_connect_time 时从未遇到过“慢”运行。但我改变的唯一提高我分数的事情只是“让 uwsgi 更快”的变化（将更多的核心用于搜索，增加数据库中的复制因子以使搜索更快）......所以是的，原来答案只是增加应用程序的吞吐量。