关于golang:nginx与后端服务长短链接配置性能差异比较

有一个服务在 qps 几万的时候偶然呈现申请 timeout 状况，因为该机器作为 p2p 下载的文件源站和服务端，之前流量会被打满时会呈现申请 timeout 的状况。然而通过优化 p2p 后最近的流量简直都不会超过 1GB/s，查看日志发现 qps 在 2 万以上就偶然呈现 timeout 的状况，很是奇怪。毕竟 golang 原生的 http 服务写个 hello word 放在服务器都能够几十万 qps 的。
该服务是通过 nginx 托管文件作为下载源，并转发客户端下载分片申请至后端服务，应用 wrk 简略压测返回简略信息的接口发现 qps 只有 4w+，且呈现局部 timeout 的谬误。应用 wrk 间接申请服务后端接口，qps 却有 30w+，wrk 间接申请 nginx 返回简略字符串 qps 也有 30W+，看来问题出在 nginx 配置上！
查看配置后发现原来 nginx 是间接转发至后端，未配置长连贯，那么一个申请来到后的过程是 client->nginx->server 要建设两次链接。
于是在本地做了几个试验验证了一下猜测。
应用的是 mbp13 2020，4C8T，电脑散热不太行 所以 qps 有所稳定，但也很能反馈问题。

1. nginx 间接返回字符串
2. golang http server 返回字符串
3. nginx+ 后端短连贯

4. nginx+ 后端长链接
   nginx 后端配置如下

   # 长连贯配置
   upstream go_http{server 127.0.0.1:13002; keepalive 300;}
   # 短连贯配置
   upstream go_http_short{server 127.0.0.1:13002;}
   server {
       listen 13001; server_name helloWorld; 
       location /nginx { 
           default_type text/html ; 
           return 200  "hello nginx"; 
       } 
       location /go { 
           proxy_pass http://go_http; 
           proxy_http_version 1.1; 
           proxy_set_header Connection "";
       } 
       location /go_short{proxy_pass http://go_http_short;}
   }

   压测命令

   # 1. nginx 间接返回字符串
   wrk -t 2 -c 100 -d 10s -H "Connection:Close" http://127.0.0.1:13001/nginx
   # 2. go http 服务间接返回字符串
   wrk -t 2 -c 100 -d 10s -H "Connection:Close" http://127.0.0.1:13002/go
   # 3. nginx 和 go http 放弃长连贯
   wrk -t 2 -c 100 -d 10s -H "Connection:Close" http://127.0.0.1:13001/go
   # 4. nginx 和 go http 采纳短连贯
   wrk -t 2 -c 100 -d 10s -H "Connection:Close" http://127.0.0.1:13001/go_short

   最初后果 1 和 2 约为 6~7 万的 qps，3 为 4~5 万 qps，4 仅有 3~4 千 qps
   线上服务的相干测试后果为 30~40 万 qps，而原来的配置只有 5 万 qps 左右。
   另外 nginx 其余参数优化及配置约有设置 worker 数量、敞开惯例日志、设定最大连接数等等就不一一赘述。