
Nginx のプロキシ バッファリングを無効にすると、アプリ サーバーが Nginx の代わりにクライアントの応答を待機するため、多くのオープン接続が表示されるはずですが、私のテストではそうではありませんでした。
設定:
client (10.2.0.7) <===> Nginx (10.2.0.5) <===> PythonApp (10.2.0.4, port 8000)
クライアントによって開始された 500 の低速接続
slowhttptest -c 500 -H -g -o my_header_stats -i 10 -r 50 -t GET -u http://pythonapp.com -x 24 -p 3
Nginx 会議:
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events
{
worker_connections 768;
# multi_accept on;
}
http
{
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
include /etc/nginx/mime.types;
default_type application/octet-stream;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
# gzip on;
upstream pythonapp
{
server 10.2.0.4:8000;
}
proxy_buffering off;
server
{
listen 80;
proxy_buffering off;
server_name pythonapp.com;
location /
{
proxy_buffering off;
proxy_pass http://pythonapp;
}
}
# include /etc/nginx/conf.d/*.conf;
# include /etc/nginx/sites-enabled/*;
}
クライアントから PythonApp サーバーへの低速接続を直接開始すると、多数のオープン接続が表示されます。セットアップ:
client (10.2.0.7) <===> PythonApp (10.2.0.4, port 8000)
クライアントによって開始された 500 の低速接続
slowhttptest -c 500 -H -g -o my_header_stats -i 10 -r 50 -t GET -u http://10.2.0.4:8000 -x 24 -p 3
私の質問は
- Nginx がリバースプロキシした後、アプリケーションサーバーに開いている接続があまりないのはなぜですか?
- 設定が間違っている場合、有効なリモート バッファリングと無効なリモート バッファリングのパフォーマンスまたはスループットの違いを示すために、対応する環境を設定するための明示的なコードと構成例を提供できますか?
答え1
ついに、プロキシバッファリングの有効/無効のスループットの違いをテストする方法を見つけました。slowtest
これはテストに適したツールではないと思います。働く
私の新しいセットアップ:
Slow client (10.2.0.7) \
\
Nginx (10.2.0.5) <===> PythonApp (10.2.0.4, port 8000)
/
/
Fast client (10.2.0.6)
これを参考にしてくださいデジタルオーシャンガイドFlask アプリ Python アプリをセットアップするには:
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "<h1 style='color:blue'>Hello There!</h1>"
@app.route("/big-file")
def big_file():
return "<h1 style='color:blue'>" + "Hello There!"*1000000 + "</h1>"
if __name__ == "__main__":
app.run(host='0.0.0.0')
遅いクライアント:
# modprobe ifb
# ip link set dev ifb0 up
# tc qdisc add dev eth0 ingress
# tc filter add dev eth0 parent ffff: \
protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0
# tc qdisc add dev ifb0 root netem delay 750ms
高速クライアントと低速クライアントで wrk テストを実行します。
遅いクライアント:
# wrk -t4 -c10 -d30 http://pythonapp.com/big-file
高速クライアント:
# wrk -t2 -c100 -d10 http://pythonapp.com
低速クライアントが/big-fileパスにアクセスするには、かなり大きなレスポンスを返す必要があります。レスポンスがプロキシバッファサイズ、Nginx とプロキシ サーバー間の接続は非常に早く閉じられ、ブロックをシミュレートすることはできません。
Nginx で proxy_buffering がない場合に低速クライアントによって占有される接続と高速クライアントのスループット:
プロキシバッファリングがない場合の高速クライアントのスループット
proxy_buffering がある場合、低速クライアントによって占有されている接続は表示されません。まず低速クライアント用のコマンドを実行して低速応答をダウンロードし、次に Nginx で接続を確認できます。