brpc长连接问题
问题:
使用了brpc的长连接,但是为何耗时和短链接一样呢?
brpc文档里介绍,使用http协议,则默认使用pooled,只要连接数不超过max_connection_pool_size,则都可以使用长连接。
但是在实际使用中,发现整个请求耗时很长,使用curl结果如下:
curl -s -w %{time_namelookup}"\r\n"%{time_connect}"\r\n"%{time_pretransfer}"\r\n"%{time_starttransfer}"\r\n"%{time_total}"\r\n" -d "" http://xxx.com/abc/123
time_namelookup : 0.000
time_connect : 0.033 TCP建立连接耗时.
time_pretransfer : 0.033 TCP连接建立完成后,客户端开始传递第一个字节的时间
time_starttransfer : 0.070 服务端响应开始传输第一个字节的时间 (虽然很多资料上说是服务端响应第一个字节的时间,但是根据我多次试验数据我更认为是:客户端收到服务端响应的第一个字节的时间)
time_total : 0.070 整个请求到响应完成的耗时
由此看出:
TCP建立连接,三次握手,耗时1.5RTT,耗时33ms;
数据传输:70-33=37ms,也就是客户端把数据传给服务端(0.5RTT) + 服务端处理(对方说5ms) +服务端把数据传回客户端(0.5RTT) = 37ms;也就是说1RTT = 32ms.
误区:
开始一直认为服务端内部有32ms(37-5)不知道哪去了,但是没想到的是我竟然把数据传输的1RTT给忽略了。
因为建立连接需要33ms,传输数据也需要32ms,服务端数据处理需要5ms,如果每次请求建立成功了长连接,则就可以省去TCP建联的33ms,也就是整个请求是37ms,符合预期。
结论:
从线上统计请求好时看,平均耗时70ms,所以可以确定长连接没建立成功。
解决:
既然brpc介绍用pooled连接池是长连接,那会不会是连接超过max_connection_pool_size了,所以很多都是短连接? 于是调得更长,也不行。
netstat -ant|awk '{print $NF}'|sort|uniq -c 分析:
61 CLOSE_WAIT
1 established)
2212 ESTABLISHED
1 FIN_WAIT2
19 LISTEN
1 State
2016 TIME_WAIT
TIME_WAIT有2016个,说明有很多连接主动关闭,也就意味着请求是短链接,频繁连接关闭,那么可以确定,尽管使用了pooled,依然是端连接。
继续分析:发现有个defer_close_second参数,表示连接是立即关闭还是延迟多少秒后关闭。将该参数值从0改为120后,请求耗时从70ms降低到35ms了。
也是奇怪,既然pooled用长连接了,为何还要用defer_close_second来把问题复杂化?