http 连接池的那三个超时时间是怎么算的

[luxinfl]

已经配置了获取连接时间 100 ，建立连接时间 20 ，读取数据时间 200 。但是大批量并发调用的时候，自己打印的 log 在超时的时候选超过 320ms 的时间，零散的 800+ms 。是连接数不够了麽？ cpu 和内存的负载才一半。

[seckill]

第一，起始时间从哪里开始计算？
第二，连接池的数量和并发的数量各是多少？

[luxinfl]

@seckill 1.用的 resttemplate ，打印时间包在 postFor
Entity 外面 2.tmocat 默认配置 200 线程，defaultMaxPerRoute 是 150 。并发数量上万 qps 。

[xiangyuecn]

第 99ms 连接已建立

第 100ms 收到第 1 字节

第 299ms 收到第 2 字节

第 498ms 收到第 3 字节

...

发送端就是玩🐶 你应该明白 800+ms 怎么来的了吧，最后一个 timeout 是沙雕功能

[luxinfl]

@xiangyuecn 这是数据获取时间是用 readTimeout 控制的吧，会存在这种情况麽？

[xiangyuecn]

readTimeout 一般是距离上次获得数据后，再也没有收到数据的超时时间，这个时间并不是从建立连接开始计算。

但这种功能大部分情况下不是开发者想要的，大部分想要的超时配置，是从发起请求开始，超过多久还没有结束，就直接 cancel 掉，管你什么获取连接，建立连接，读取超时，可惜那伙人不直接给这种配置

[luxinfl]

@xiangyuecn 那我和第三方服务建立连接以后，读取数据的总耗时不就是 read timeout 时间控制的么。现在问题是完整的的连接耗时超过了配置的三个参数总和，而且超过很多。。。这说不通啊，难道是日志打印的问题？

[chengyiqun]

@xiangyuecn 同, 以前被这个困扰过, 后来不管了

[xiangyuecn]

@luxinfl #6 你想要的这种超时控制，一般没有直接的配置可以用的，得自己写定时器，所以我说这玩意沙雕的很😂

我的原话是：“readTimeout 一般是距离上次获得数据后，再也没有收到数据的超时时间，这个时间并不是从建立连接开始计算。”

[luxinfl]

@xiangyuecn 有相关代码可以参考一下么，大佬

[FrankAdler]

可以每个小环节都收集下时间看看，负载较高时计时器不准很正常吧，或者还有部分时间没有被你理解到，比如 dns 解析耗时，中间数据处理耗时等