django-tastypie を使用して、API を介してモバイル アプリにデータをフィードするサイトがあります。私たちの API に対して最初の apache-benchmark テストを行ったとき、パフォーマンスが期待したほど良くないことに気付きました (私の期待を裏付ける確固たる基盤がないことを認めなければなりません)。私のサーバーのセットアップは次のとおりです：2.4GHZ 2コアCPU、2560Mメモリ、ubuntu12.04。uwsgi で nginx を使用し、uwsgi で 4 つのワーカーを使用するように設定し、nginx で 4 つの worker_processes も使用します。
これは、API エンドポイントからの私の結果です。クエリは 7 つのテーブルにまたがり、30 以上のクエリがあり、多数のネストされたリソースがあります。SQL クエリのプロファイリングを行ったところ、そのうち 3 つだけが 1 ミリ秒を超えていました (それぞれ 1 ミリ秒、1 ミリ秒、2 ミリ秒)。
ab -n 100 -c 8 -H 'Accept-Encoding: gzip' "http://mysite"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
Benchmarking lvxingjia.cc (be patient).....done
Server Software: nginx/1.4.1
Server Hostname: mysite
Server Port: 80
Document Path: mysite
Document Length: 10807 bytes
Concurrency Level: 8
Time taken for tests: 19.146 seconds
Complete requests: 100
Failed requests: 0
Write errors: 0
Total transferred: 1117500 bytes
HTML transferred: 1080700 bytes
Requests per second: 5.22 [#/sec] (mean)
Time per request: 1531.720 [ms] (mean)
Time per request: 191.465 [ms] (mean, across all concurrent requests)
Transfer rate: 57.00 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 16 37 56.5 23 485
Processing: 775 1455 238.1 1502 1901
Waiting: 765 1443 237.8 1488 1889
Total: 794 1492 235.7 1555 1920
Percentage of the requests served within a certain time (ms)
50% 1555
66% 1626
75% 1653
80% 1694
90% 1758
95% 1783
98% 1903
99% 1920
100% 1920 (longest request)
私はパフォーマンス チューニングにかなり慣れていませんが、現在はトラフィックがあまりないので、ひどいものでなければわざわざやりたくありません。
私の最初の質問は、サーバーのリソースとリクエストの複雑さを考えると、その数は妥当ですか?
2 番目の質問は、この数値が許容範囲を超えている場合、改善するためにどの領域を調べる必要があるかということです。DB クエリ、ラインプロファイリング django? ライン プロファイリングの結果を取得しました。実際には、他のユーザーからも報告されていたディープコピーでの Tastypie の問題が確認されました。monky-patch により、パフォーマンスが約 30% 向上しました。
ここにも素晴らしい投稿があります: Bad Django / uwsgi performance , しかし、サーバー/リクエストのシナリオを考えると、私の状況について何らかの意見があると思います.
ありがとう！