brpc访问MySQL_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来把问题复杂化？