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

Posted 2021-09-14 mumuhere

有一个服务在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，设定nginx worker数量为1，golang后端也只限制单核，电脑散热不太行 所以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; 
    }
}

使用wrk压测

# 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约为5~7万的qps，3为4~5万qps，4仅有3~4千qps
线上服务修改nginx与后端配置后相关测试结果为30~40万qps，而原来的配置只有5万qps左右。
另外nginx其他参数优化等等就不一一赘述。

由此可见，nginx在配置与后端的服务时最好保持为长连接，防止nginx频繁与后端创建关闭造成严重浪费。