有一个服务在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数量、敞开惯例日志、设定最大连接数等等就不一一赘述。