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的上下文中，这非常重要，因为如果没有工作人员可以接受请求，那么请求将被放在待办事项上。我认为请求在backlog上等待的时间可能算作upstream_connect_time，而不是nginx中的upstream_response_time，因为uwsgi还没有读取任何字节。

不幸的是，我无法100％肯定，因为我从未得到过＆＃34;慢＆＃34;运行我记录upstream_connect_time的地方。但是我改变的唯一能改善我得分的东西只是让你的uwsgi变得更快＆＃34;更改（将更多内核用于搜索，增加数据库中的复制因子以使搜索更快）...所以是的，结果答案只是为了增加应用程序的吞吐量。

nginx和uwsgi：上游响应时间和请求时间之间的巨大差异

1 个答案: