Question

在尝试对我的烧瓶应用进行基准测试时，我遇到了一些与Nginx + uWSGI +烧瓶有关的问题。我的测试显示，这种组合很慢。我在具有4个内核和4 GB RAM的Ubuntu 12.04 VM上全新安装了Nginx 1.1.19和uWSGI 2.0。（下面是Nginx和uWSGI配置）

我做了一个Nginx的基准测试，它自己提供一个静态的20字节文件，并且我能够获得高达80k req / sec。然后我做了Nginx + uWSGI的基准测试+一个非常基本的烧瓶应用程序（烧瓶现场的Hello world示例），我只能获得最大8k req / sec（减少10倍）

我打开登录Nginx和uWSGI（加上stats套接字）并格式化日志以打印两者的请求处理时间，这是我能够收集的内容：

uWSGI avg。请求时间= 0ms
Nginx平均请求时间= 125ms （Nginx日志时间包括在uWSGI中花费的时间）

我用我的烧瓶应用程序进行了相同的测试，结果遵循相同的模式

uWSGI avg。请求时间= 4ms
Nginx平均请求时间= 815ms

问题：看来Nginx和uWSGI之间的通信耗费了大量时间。有谁见过这个问题之前???我已经尝试过Nginx和uWSGI的所有配置都具有相同的结果。

请注意，我使用apachebench（ab）进行了测试，这些测试都是在本地VM上和具有相同结果的远程计算机上进行的。

Nginx conf

user www-data;
worker_processes 4;
worker_rlimit_nofile 200000;
pid /var/run/nginx.pid;

events {
        worker_connections  10240;
        #multi_accept on;
        #use epoll;
}

http {
        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 10;
        types_hash_max_size 2048;
        client_body_timeout 10;
        send_timeout 2;
        gzip on;
        gzip_disable "msie6";
        keepalive_disable "msie6";

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

        access_log  off;
        error_log  /var/log/nginx/error.log crit;

        log_format ugzip '$remote_addr - "$request" - $status $body_bytes_sent - [$request_time]';

        ##
        # Virtual Host Configs
        ##
        #include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;

        server {
                listen       80;
                server_name  localhost;

                access_log  /var/log/nginx-access.log  ugzip  buffer=32k;
                error_log  /var/log/nginx-error.log;

                location /myapplication {
                        uwsgi_pass     unix:/tmp/bdds.sock;
                        include         uwsgi_params;
                        uwsgi_param UWSGI_SCHEME        $scheme;
                }
        }
}

uWSGI conf （相关部分）

[uwsgi]
master                  = true
listen                  = 40000
chmod-socket            = 666
socket                  = /tmp/bdds.sock
workers                 = 8
harakiri                = 60
harakiri-verbose        = true
reload-mercy            = 8
logto                   = /var/log/uwsgi-app.log
logformat               = %(proto) %(method) %(uri) - %(status) %(rsize) - [%(msecs)]  
vacuum                  = true
no-orphans              = true
#cpu-affinity           = 1
stats                   = /tmp/stats.sock

这是Nginx + uWSGI的常见行为吗？我的配置是否有明显不正确的内容？我在使用Ubuntu 12.04的4核/ 4 GB RAM Xen VM上运行它。

提前致谢。

Answer 1

我猜你每秒发送的请求比同步部分（uWSGI + Flask）可以处理的要多得多。这使得请求在大多数时间都挂在异步部分（nginx）上。

Answer 2

每秒8k的请求并不是那么糟糕，特别是当你与一个20字节的sendfile（）服务进行比较时，这种情况基本上都发生在没有ipc的ram中。顺便说一下，你应该从uWSGI删除任何日志记录，很可能在生产中你只记录缓慢或不好的请求。

使用ab进行Nginx + uWSGI + Flask app性能测试

2 个答案: