私はDjangoプロジェクトにNginx-uWSGIの組み合わせを使用していますが、Nginx-Apache-modwsgiの組み合わせと比べてパフォーマンスは劣ります。明らかに、uwsgiは、最大で約300〜400msのサーバであるべき要求に対する応答を提供するのに約3〜5秒かかる。uWSGI-Djangoが投票方法に時間をかけすぎています
プロファイリングを実行すると、ほとんどの時間がuWSGIハンドラのresponse.render
機能で費やされていることがわかりました。ここでプロファイリング結果がある -
サーバー上のただ一つの要求があった場合でも、私は、method poll
は、時間の90%以上を消費している理由を把握することができません。
はここに私のuwsgi構成
[uwsgi]
uid = www-data
gid = www-data
listen = 10000
socket-timeout = 60
socket-send-timeout = 60
socket-write-timeout = 60
set-placeholder = username=sysadmin
set-placeholder = project_directory=/home/sysadmin/builds/deploy_dir/qa_shine
set-placeholder = ruby_shims_path=/home/sysadmin/.rbenv/shims
socket = /run/%n.sock
chmod-socket = 666
chdir = %(project_directory)
pidfile = /run/%n.pid
wsgi-file = deploy/uwsgi.py
master = true
processes = 1
threads = 1
harakiri = 160
virtualenv = /home/%(username)/Envs/candidate/
stats = 127.0.0.1:9191
vacuum = true
die-on-term = true
daemonize = /var/log/uwsgi/%n.log
env = LANG=en_US.UTF-8
auto-procname = true
env = PATH=%(ruby_shims_path):$(PATH)
env = RUBYPATH=%(ruby_shims_path)/ruby
rbrequire = rubygems
私のnginxの上流の構成
私は完全に今迷ってしまいましたlocation/{
uwsgi_pass django;
include uwsgi_params;
proxy_buffering off;
proxy_buffers 128 128k;
proxy_buffer_size 128k;
proxy_temp_path /run/ 1 2;
uwsgi_read_timeout 60;
uwsgi_send_timeout 60;
uwsgi_connect_timeout 60;
send_timeout 60;
}
# basic conf
events {
worker_connections 8192;
use epoll;
multi_accept on;
}
で、任意の助けいただければ幸いです。
異なるプロセスに対して同じライブラリを2回呼び出すのはなぜですか。そしてもう一つのポイント ''あなたのアプリケーションキャッシュを管理する方法? "'これは '' import a; import b;あなたが "(a-b)+ 2b"を得られるように#but 'a' include 'b'。各関数呼び出しごとに複数の遅延があります。 – dsgdfg
uwsgiプロセスの数を変更しようとしましたか?通常、1台のコアマシンでも少なくとも2つは必要です。あなたは、あなたのuwsgiワーカーに非同期スレッドを生成させるように指定することもできますが、これは環境とあなたが達成しようとしているものによって決まります –
ええ、一般的には2つのスレッドで10プロセスを使用します – hspandher