在尝试对我的烧瓶应用程序进行基准测试时,我遇到了一些与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平均请求时间= 0ms
Nginx平均请求时间= 125毫秒(Nginx日志时间包括在uWSGI中花费的时间)
我用烧瓶应用程序进行了相同的测试,结果遵循相同的模式
uWSGI平均请求时间= 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上运行它.
提前致谢.
解决方法:
我猜你每秒发送的请求比同步部分(uWSGI Flask)可以处理的要多得多.这使得请求在大多数时间都挂在异步部分(nginx)上.