nginx 和 uwsgi : large difference between upstream response time and request time

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 的上下文中，这非常重要，因为如果没有可用的 worker 来接受请求，该请求将被置于积压中。我认为请求等待积压的时间可能算作 upstream_connect_time，而不是 nginx 中的 upstream_response_time，因为 uwsgi 还没有读取任何字节。

不幸的是，我不能 100% 确定，因为我从来没有在记录 upstream_connect_time 的地方运行“缓慢”。但是我改变的唯一提高我的分数的事情只是“让 uwsgi 更快”的改变(投入更多的核心来搜索，增加数据库中的复制因子以使搜索更快)......所以是的，答案只是为了增加应用程序的吞吐量。