前言
一直有人反馈，说我们的域名访问，第一次经常丢失，或者延迟很严重。自己也偶尔遇见过，可是一旦成功了一次，后面的几次都会正常，很快，本次优化经历了两个问题的思考，并提供了解决方案。
- 怎么查看一次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; # 加在这里
# 省略...
解决了