13

私のdjango Webサイト（gunicorn 4ワーカー）が重い負荷で遅い理由を確認しようとしています.http://djangosnippets.org/snippets/186/のプロファイリングを行ったので、明確な答えはありませんでした。ab -n 1000 -c 100 http://localhost:8888/

シンプルな Httpreponse("hello world") ミドルウェアなし ==> 3600req/s

ミドルウェア (キャッシュされたセッション、キャッシュされた認証) を使用した単純な Httpreponse("hello world") ==> 2300req/s

フォーム (キャッシュされたテンプレート) のみを出力する単純な render_to_response ==> 1200req/s (応答時間は 2 で割りました)

50 個の memcache クエリを使用した単純な render_to_response ==> 157req/s

Memcache クエリはそれよりもはるかに高速である必要があります (私は PyLibMCCache を使用しています)。テンプレートのレンダリングはこの結果と同じくらい遅いですか?

さまざまなプロファイリング手法を試しましたが、成功しませんでした。

$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 46936
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 400000
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 46936
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

$ sysctl -p

fs.file-max = 700000
net.core.somaxconn = 5000
net.ipv4.tcp_keepalive_intvl = 30

私はubuntu 12.04（RAMの6Go、コアi5）を使用しています

何か助けてください。

4

2 に答える 2

1

memcached リクエストを実行し、新しい接続を開くのにかかる時間に大きく依存します (リクエストが終了すると、django は接続を閉じます)。ワーカーと memcached の両方がより多くのストレスを処理できますが、もちろん 5/ memcached 呼び出しを実行するのに 10 ミリ秒かかると、そのうちの 50 がボトルネックになります。これは、ネットワーク レイテンシに呼び出し回数を掛けた値になるためです。

現在、django、gunicorn、マシン、およびネットワークのベンチマークを行っています。

このレベルで何か極端に間違っている場合を除き、このテストで興味深い発見が得られることはありません。

アプリの実行が遅くなっているのは、db と memcached の使用方法 (およびおそらくテンプレート レンダリング時) に関連している可能性が非常に高いです。

このため、django デバッグ ツールバーを入手して、実際のページで何が起こっているかを確認することを強くお勧めします。

memcached への接続を開くことがボトルネックであることが判明した場合は、接続プールを使用して接続を開いたままにすることができます。

于 2013-03-09T13:40:29.273 に答える
0

memcached のパフォーマンスを調査できます。

$ python manage.py shell
>>> from django.core.cache import cache
>>> cache.set("unique_key_name_12345", "some value with a size representative of the real world memcached usage", timeout=3600)
>>> from datetime import datetime
>>> def how_long(n):
        start = datetime.utcnow()
        for _ in xrange(n):
            cache.get("unique_key_name_12345")
        return (datetime.utcnow() - start).total_seconds()

この種のラウンドトリップ テストでは、サーバーで 1 回の memcached ルックアップに約 0.2 ミリ秒かかることがわかりました。

django.core.cache と pylibmc の問題は、関数がブロックされていることです。HTTP 要求の往復で、その数の 50 倍を取得する可能性があります。0.2 ミリ秒の 50 倍は、すでに 10 ミリ秒です。

memcached を使用せずに 4 つのワーカーで 1200 リクエスト/秒を達成した場合、平均 HTTP ラウンドトリップ時間は 1/(1200/4) = 3.33 ミリ秒でした。それに 10 ms を追加すると、13.33 ms になります。4 ワーカーのスループットは 300 req/s に低下します (これはたまたま 157 数の球場にあります)。

于 2014-01-29T13:46:27.093 に答える