すべてのページがnginxのhttpキャッシュから提供され、無効化または期限切れになることはめったにないWebサイトがあります。
ページの平均ダウンロードサイズは約2MBですが、面白いロジックのない静的サイトであるにもかかわらず、サーバーの応答は約1秒です。
Nginxの$request_time
を記録しましたが、サーバーから約400ミリ秒になります
各ファイルの平均は20〜30 KB
400ミリ秒はばかげているようです。
私は遅れていますCloudflareそして
sendfile on;
tcp_nopush off;
tcp_nodelay on;
keepalive_timeout 300s;
keepalive_requests 10000;
応答時間を150ミリ秒の範囲に下げるにはどうすればよいですか?
編集:私のチューニングの最初の部分。
SSLOSCPをオンにしていないことに気づきました。コードを微調整して
# https://github.com/autopilotpattern/wordpress/issues/19
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1d;
ssl_certificate /etc/letsencrypt/live/site.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/site.com/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/site.com/chain.pem;
ssl on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;
ssl_stapling on;
ssl_stapling_verify on;
改善について報告します。
編集2:
これは、インドから米国西海岸のサーバーへの3G接続ヒットのWebページテスト結果です。
私はあなたが最適化の質問をしているとは思わない。まず、時間がどこに向かっているのかを知る必要があります。
ブラウザに表示する時間について話しているとは思わないので、当面はブラウザを除外してください。 curlやabなどの軽量のコマンドラインツールを使用して、タイミング情報を収集します。デスクトップ、またはこのサイトにサービスを提供しているサーバー以外の適切に接続されたサーバーからこのようなツールを使用すると、ローカルシステム、ネットワーク、またはブラウザーの問題を除外するのに役立つ場合があります。
Ab(Apacheツールに付属)またはcurlを使用していくつかのテストを実行し、サーバー上で実行して、ネットワークの遅延とクラウドフレアを全体像から取り除きます。 DNSが指す場所ではなく、ローカルhttpサーバーへの接続を取得するためのオプションを試して、適切なHost
ヘッダーを使用する必要があります。あなたの遅れは今どのように見えますか?これにより、問題がWebサーバーにあるのか外部にあるのかがわかります。これにはnginxキャッシュの利点が含まれますが、cloudflareからのキャッシュは含まれません。
サーバーのこのビットが高速である場合は、cloudflareとネットワークを調べています。それ以外の場合は、サーバーを見続けてください。
クライアントの観点からリクエストにかかる時間を確認するだけでなく、nginxログ形式を変更して、ログでより多くのタイミング情報を取得することもできます。私は通常、次のようなものを使用します。
log_format combined '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$request_time" "$msec"';
状況が許せば、使用するほとんどのサーバーでこのログ設定を永続的に設定したままにします。
ログの$request_time
フィールドに遅延が記録されているのがまだ表示されている場合は、top
またはatop
などが、時間がnginx内で費やされているかどうかを判断するのに役立つ場合があります。他のプロセスを待っています。
どの種類のプロセスに遅延があるかを把握すると、strace
を使用して何が起こっているのかを把握できる可能性があります。 ltrace
も同様に役立つ場合があり、デバッガーを使用して完全なプロファイルに移動したり、タイミング情報をトレースしたりする必要がある場合もありますが、通常はかなり時間のかかるアプローチです。間違いなくstrace
で始まります。
もう少し質問があると思いますが、懸念される可能性のあるすべての領域の詳細に焦点を当てるのではなく、上記を試してから、見つけたものについてさらに詳細を追加してみてはどうでしょうか。