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

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

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

我已经研究过这个问题，我发现的所有线程都说这总是由客户端连接缓慢引起的。但是，请求是由同一网络上的脚本发出的，并且这个问题不会影响其他任何人的设置，因此在我看来，这是我的nginx配置的问题。这让我完全被难住了，因为nginx成为这样的瓶颈似乎是前所未闻的

为了了解问题的严重性，有三种主要的请求类型：添加图像、搜索和添加tweet（这是twitter的克隆）

对于添加映像，总体请求时间平均比上游响应时间长约20倍。对于搜索，它是3的一个因子，加上tweet 1.5。我的理论是，添加图片比搜索或添加tweet来回发送的数据量大得多，搜索比添加tweet来回发送的数据量大得多

我的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

---

如果您能深入了解此问题的原因，我们将不胜感激

所以，我想我找到了答案。通过阅读nginx文档（），似乎有三个指标需要注意：上游响应时间、请求时间和上游连接时间。我关注的是上游响应时间和请求时间之间的差异

但是，上游响应时间是上游接受请求和返回响应之间的时间。它不包括上游连接时间，也不包括与上游服务器建立连接所需的时间。在uwsgi的上下文中，这一点非常重要，因为如果没有可用的工作人员来接受请求，那么请求将被提交到待办事项中。我认为在nginx中，请求等待待办事项的时间可能算作上游连接时间，而不是上游响应时间，因为uwsgi还没有读取任何字节

---

不幸的是，我不能百分之百确定，因为我从来没有在记录上游连接时间的地方“慢”跑过。但我改变的唯一能提高我成绩的事情就是“让uwsgi更快”的改变（将更多的内核用于搜索，增加数据库中的复制因子以使搜索更快）。。。所以，是的，答案只是为了增加应用程序的吞吐量

在日志条目中使用大写键是个好主意！