
私は、ライブ ストリーミング (HLS) 用の .ts ファイルを提供するために Nginx を使用しています。すべて正常に動作しますが、ファイルの応答時間に問題があります。時々、サーバーから受信した一部の .ts ファイルの応答時間が予想外に長くなることがありますが、これは私たちのユースケースでは問題となります。
問題が何であるかを調べるために Python スクリプトを使用しました。
このスクリーンショットでは、完全な応答時間は、リクエストが送信されてから完全な応答が受信されるまでの時間です。 2 番目に表示されるパラメータは、リクエストが送信されてから応答が受信されるまでの時間です (私は、Python のリクエスト パッケージの response.elapsed.total_seconds() を使用しました)。 遅いリクエストでは、完全な応答時間は長くなりますが、response.elapsed.total_seconds() は問題ありません (ここで言う「長い」とは、平均応答時間の 3 ~ 4 倍を意味します)。
この問題に加えて、応答時間 (response.elapsed.total_seconds()) と全応答時間の両方が長いという別の問題があります。このケースはそれほど頻繁には発生せず (おそらく 200 リクエストにつき 1 回)、応答時間は最初のケースよりもはるかに長くなります。
このマシンの前に、プロキシしてファイルをキャッシュするための他のマシンがいくつかあることを述べておきます。ただし、キャッシュ マシンを要求するか、メイン マシンを要求するかは関係ありません。結果は同じです。
私の Nginx 設定は次のとおりです:
user root;
worker_processes 16;
worker_rlimit_nofile 1000000;
master_process on;
pid /run/nginx.pid;
events {
worker_connections 500000;
accept_mutex off;
multi_accept off;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
sendfile on;
tcp_nopush on;
server_tokens off;
keepalive_timeout 150;
# keepalive_requests 5;
aio on;
gzip on;
client_header_buffer_size 1k;
large_client_header_buffers 4 4k;
client_body_buffer_size 1k;
client_max_body_size 1k;
client_body_timeout 12;
client_header_timeout 12;
send_timeout 10;
tcp_nodelay on;
sendfile_max_chunk 1m;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.2;
proxy_intercept_errors on;
proxy_http_version 1.1;
vhost_traffic_status_zone shared:vhost_traffic_status:10m;
underscores_in_headers on;
recursive_error_pages on;
server {
listen 80 backlog=10000000;
location /tmp {
access_log /cache/nginx.log main;
types {
application/vnd.apple.mpegurl m3u8;
video/mp2t ts;
}
alias /cache/hls;
add_header Cache-Control no-cache;
}
}
Nginx のアクセス ログとエラー ログには、異常は何も表示されません。応答が良好でも、応答が遅い場合でも、異常は表示されません。
今までこの問題について何も見つけられませんでした。ここで答えが見つかるといいのですが。