在尝试对我的烧瓶应用程序进行基准测试时,我遇到了一些与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平均值.REQ时间= 125ms的(Nginx的日志时间包括在uWSGI花费的时间)
我用烧瓶应用程序进行了相同的测试,结果遵循相同的模式
uWSGI平均 req time = 4ms
Nginx avg.请求时间= 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上运行它.
提前致谢.