【テスト】Guniorn,uWSDI同期非同期テストおよびアプリケーションシーンのまとめ

最近uwsgiを使っていくつか問題が発生したので、テストの下でGuniornテストの比較の下で

環境

バックエンドアプリケーションとしてcpu 1 gメモリCentosシステムDjango、Guncornデフォルトモードと非同期モード、応答は基本的にブロックなしタイプ

テストrequestは暗号化操作であり、urlのいくつかのパラメータに対してase暗号化

を行う.

説明:次のシミュレーションブロックモードは、ネットワーク遅延による応答が長い

のため、リクエストにサードパーティapiを呼び出すシーンがたくさんあるのと同様です.
テストコマンド

ab -n 10000 -c 100 -r 'http://127.0.0.1:8888/account/ulogin/3/?wlanuserip=127.0.0.1&wlanacname=&ssid=cmcc&wlanparameter=ffffffffffff'
#  -n 1000
ab -n 1000 -c 100 -r 'http://127.0.0.1:8888/account/ulogin/3/?wlanuserip=127.0.0.1&wlanacname=&ssid=cmcc&wlanparameter=ffffffffffff'

Gunicorn同期非同期テスト

起動パラメータの適用

 
gunicorn -b 0.0.0.0:8888 wsgi:application

 
gunicorn -b 0.0.0.0:8888 -k 'gevent' wsgi:application

テスト統計

数字の意味:総時間qpsエラー数

要求処理ブロックなし:

デフォルトモードworker:27.5 s,364,0;26.3 s,261,0非同期モードworker:31.9 s,312,0;31s,314,0

要求ごとに0.1秒のブロックが増加した後:

デフォルトモード:すでに10未満に下がったqps非同期モード:依然として以前の速度と300 qps程度に相当することができます
Guncorn設計は同期を使用するか非同期workerを使用するか、どのworkerを使用するかについて詳細なアドバイスがあります.

uWSDI同期非同期テスト

起動パラメータの適用

# 
uwsgi --http :8888 --module wsgi --process 1 -l 1000

# 
uwsgi --http :8888 --module wsgi -l 1000 --async 100 --ugreen  # 

テスト統計

数字の意味:総時間、qps、エラー

一般的な要求:

デフォルトモード:26 s,385,0;26.2 s,380,0非同期モード:26.8 s,373,0;25.9s, 385, 0

各要求0.1 sブロック要求の下:

デフォルトモード:109 s,9,0;103 s,9.6,0非同期モード:104 s,9.6,0;106 s,9.2,0#は基本的に同期モードと変わらない
uWSDiドキュメントasyncの説明の冒頭に警告があります.appが時間駆動でない場合、このモードを使用するのは間違っています.はっきり言って、uwsgiのイベントモードは実はバックエンドのイベントフレームワークに対応して、例えばgeventオプションを使って、バックエンドはgeventでやっと有効で、もしバックエンドがdjangoであれば、実はどのように配置してもあまり違いがなくて、djangoのwsgiに対して非同期の操作をしました.

まとめ

応答時間の短いアプリケーションでは、uWSDI+djangoは良い組み合わせです(テストの結果は少し利点がありますが)、一部のブロックリクエストGuncorn+gevent+djangoが非常に効率的であれば、ブロックリクエストが多い場合はtornadoで書き換えましょう.