提高qps，http通道显示BROKEN

[guodongxiaren]

Describe the bug (描述bug)
50qps左右。通过brpc自带的监控页面看http下游是BROKEN状态。下游性能没问题。

打印controller的错误码为：112。链接下游异常。其实下游没问题。

To Reproduce (复现方法)
压测升到qps。实际也不是特别高的qps。几十而已。

Expected behavior (期望行为)

Versions (各种版本)
OS:
Compiler:
brpc:
protobuf:

Additional context/screenshots (更多上下文/截图)

[yinqiwen]

似乎是个client实现的隐藏bug，不局限于http，我们遇到的现象:

1. Redis Channel(wrr with nameservice)
2. 系统运行一段时间，qps升高到一定程度后，CallMethod基本全是E112 错误无法恢复（偶尔有E110连接超时）
3. 重启整个服务会恢复

[guodongxiaren]

@jamesge

[guodongxiaren]

似乎是个client实现的隐藏bug，不局限于http，我们遇到的现象:

1. Redis Channel(wrr with nameservice)
2. 系统运行一段时间，qps升高到一定程度后，CallMethod基本全是E112 错误无法恢复（偶尔有E110连接超时）
3. 重启整个服务会恢复

对。。我们http client出现问题的时候。redis client 也跟着一起恶化了。只是没http严重

[cdjingit]

哪个brpc版本? wrr + ns具体如何配置的？用example/redis_c++能复现吗？

[yinqiwen]

0.9.7, ns是内部的和bns实现差不多，单独比较难复现，一般在一天流量高峰时触发一次。（改过rr + ns也一样）

[chenzhangyi]

用的是连接池?

[yinqiwen]

CONNECTION_TYPE_POOLED 和pipeline方式都试过， 观察的是pipeline更容易触发上面的问题

[cdjingit]

E112是lb选不出健康节点了。服务本身负载怎么样呢？有没有开启熔断功能？

[yinqiwen]

可能高峰时server负载也比较高吧。 但client最后全部陷入E112错误无法恢复， redis server的这时压力是0 caidj <notifications@github.com> 于2020年10月21日周三 上午11:27写道：

…

E112是lb选不出健康节点了。服务本身负载怎么样呢？有没有开启熔断功能？ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1271 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABWMT44SORPGSRQCU7SO2LSLZILRANCNFSM4SYJS7IQ> .

-- yinqiwen

[gydong]

@yinqiwen ChannelOptions.timeout_ms 和 ChannelOptions.connect_timeout_ms 这两个选项的值分别设置了多少？

[yinqiwen]

connect timeout未设置 rpc timeout 50ms gydong <notifications@github.com> 于 2020年10月21日周三 下午12:42写道：

…

ChannelOptions.timeout_ms 和 ChannelOptions.connect_timeout_ms 这两个选项的值分别设置了多少？ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1271 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABWMTZP47Z4W4IQZEMHIWLSLZRDFANCNFSM4SYJS7IQ> .

[gydong]

connect timeout未设置 rpc timeout 50ms gydong notifications@github.com 于 2020年10月21日周三 下午12:42写道：
…
ChannelOptions.timeout_ms 和 ChannelOptions.connect_timeout_ms 这两个选项的值分别设置了多少？ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1271 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWMTZP47Z4W4IQZEMHIWLSLZRDFANCNFSM4SYJS7IQ .

ChannelOptions.connect_timeout_ms 设置成30ms，看看是否还能复现你之前的问题

[guodongxiaren]

connect timeout未设置 rpc timeout 50ms gydong notifications@github.com 于 2020年10月21日周三 下午12:42写道：
…
ChannelOptions.timeout_ms 和 ChannelOptions.connect_timeout_ms 这两个选项的值分别设置了多少？ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1271 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWMTZP47Z4W4IQZEMHIWLSLZRDFANCNFSM4SYJS7IQ .

ChannelOptions.connect_timeout_ms 设置成30ms，看看是否还能复现你之前的问题

@gydong

连接断开。brpc client会自动重连吗？

另外我们下游只有一个固定ip和端口。pooled的方式有没有问题？

[yinqiwen]

connect timeout未设置 rpc timeout 50ms gydong notifications@github.com 于 2020年10月21日周三 下午12:42写道：
…
ChannelOptions.timeout_ms 和 ChannelOptions.connect_timeout_ms 这两个选项的值分别设置了多少？ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1271 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWMTZP47Z4W4IQZEMHIWLSLZRDFANCNFSM4SYJS7IQ .

ChannelOptions.connect_timeout_ms 设置成30ms，看看是否还能复现你之前的问题

是代码里和这个有关？ 另外有个服务设置了connect_timeout_ms = 500 也有同样的现象

[gydong]

connect timeout未设置 rpc timeout 50ms gydong notifications@github.com 于 2020年10月21日周三 下午12:42写道：
…
ChannelOptions.timeout_ms 和 ChannelOptions.connect_timeout_ms 这两个选项的值分别设置了多少？ — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1271 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWMTZP47Z4W4IQZEMHIWLSLZRDFANCNFSM4SYJS7IQ .

ChannelOptions.connect_timeout_ms 设置成30ms，看看是否还能复现你之前的问题

是代码里和这个有关？ 另外有个服务设置了connect_timeout_ms = 500 也有同样的现象

我记得之前有个问题是如果connect timeout设置的比timeout大，则会导致一直触发rpc timeout而走不到连接超时的控制逻辑。我在应用过程中，之所以没遇到这个问题，是因为我们开启了熔断，规避了这个问题。