序文
ドメイン名へのアクセスが最初に失われることが多い、または遅延が非常に深刻であるというフィードバックがあります。たまに遭遇しましたが、一度成功すれば、次の数回は正常になります。まもなく、この最適化は2つの問題を経て、解決策を提供します。
- httpリクエストの確認方法、各モジュールには時間がかかります。
- この時間のかかるものを最適化する方法
カール
curl -o /dev/null -s -w time_namelookup:"\t"%{
time_namelookup}"\n"time_connect:"\t\t"%{
time_connect}"\n"time_appconnect:"\t"%{
time_appconnect}"\n"time_pretransfer:"\t"%{
time_pretransfer}"\n"time_starttransfer:"\t"%{
time_starttransfer}"\n"time_total:"\t\t"%{
time_total}"\n"time_redirect:"\t\t"%{
time_redirect}"\n" https://请求地址
time_namelookup: 0.034220
time_connect: 3.052509
time_appconnect: 3.144182
time_pretransfer: 3.144239
time_starttransfer: 3.190434
time_total: 3.194743
time_redirect: 0.000000
今回はたまたま少し遅いシチュエーションを見つけましたが、実際のシチュエーションでは9秒以上、さらにはタイムアウトのシーンもありました。
オーバーヘッドのほとんどがtime_connectにあることがわかります。つまり、httpsのハンドシェイクオーバーヘッドは巨大です。
- ただし、すべての最初の接続が遅いわけではありません。
- ビジネスサービスが遅いために、nginxリバースプロキシの単一実行時間が長くなりすぎてキューイングが発生している可能性がありますか？サーバートップ、free -hおよびその他のインジケーター、ドメイン名へのイントラネットアクセス、およびビジネス（ golang prof）はすべて非常に高速で、除外されています。
- 帯域幅の問題でしょうか？サーバーコンソールにログインして、帯域幅の使用量が正常であることを確認します。
したがって、特定の時間または数回のハンドシェイクがキューで保留にされたと推測します。
- nginxワーカーがデフォルト設定でショートボードされている可能性はありますか？結局のところ、nginxはデフォルト構成を使用します。
最適化
cd /etc/nginx
cat nginx.conf ## 发现没有预设worker_rlimit_nofile,该字段默认只有一千多，表示nginx最大同时操作的文件句柄
nginx.confを変更し、最上位にworker_rlimit_nofileを追加します
# For more information on configuration, see:
# * Official English Documentation: http://nginx.org/en/docs/
# * Official Russian Documentation: http://nginx.org/ru/docs/
#user root;
user nginx;
worker_processes auto;
error_log /var/log/nginx/error_log;
pid /run/nginx.pid;
worker_rlimit_nofile 65535; # 加在这里
# 省略...
解決しました