记录一次https服务优化

前言

一直有人反馈，说我们的域名访问，第一次经常丢失，或者延迟很严重。自己也偶尔遇见过，可是一旦成功了一次，后面的几次都会正常，很快，本次优化经历了两个问题的思考，并提供了解决方案。

• 怎么查看一次http请求，各个模块耗时。
• 怎么优化掉这种耗时

curl

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

本次只是正好发现了一次稍微慢一点的情况，实际情况中，出现过9s以上，甚至timeout的场景。

可以发现，大部分开销都在time_connect上，也就是https的握手开销巨大。

• 可是，并不是每次第一次连接都很慢。
• 会不会是业务服务缓慢，导致nginx反向代理单次执行时间过长，引起排队?查看服务器top，free -h等指标，内网访问域名，业务(golang prof)均很快，排除。
• 会不会是带宽问题？登录服务器控制台，发现带宽使用率很健康。

所以猜测，某次或某几次的握手，被排队搁置了。

• 有没有可能，是nginx的worker被默认配置短板了。毕竟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; # 加在这里

# 省略...

解决了