
비활성화된 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에서 연결을 확인할 수 있습니다.