提高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而走不到连接超时的控制逻辑。我在应用过程中，之所以没遇到这个问题，是因为我们开启了熔断，规避了这个问题。

[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 也有同样的现象

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

所以开启enable_circuit_breaker也能解决？ 我们回头都试下

[guodongxiaren]

@gydong 下游只有一个地址的。。能熔断吗。熔断就没了

[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 也有同样的现象

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

所以开启enable_circuit_breaker也能解决？ 我们回头都试下

回头看了下，有个服务设置rpc timeout 300ms， connect timeout未设置（默认是200）仍然有这个问题

[cdjingit]

@gydong 下游只有一个地址的。。能熔断吗。熔断就没了

是熔断会导致这个问题，返回EHOSTDOWN(E112），你的case是直连的单个地址吗？没有使用名字服务？
brpc/exmaple/http的demo能否复现？不能的话，可能是服务本身和环境的问题。可以看下出问题时的连接状态，和抓包看看。

[guodongxiaren]

@yinqiwen 请问你那边有啥进展吗？

[yinqiwen]

@yinqiwen 请问你那边有啥进展吗？

还能重现

[guodongxiaren]

@jamesge @gydong BROKEN的时候会出现大量TIME WAIT。默认的conntect type不是短链接把。下游是HTTP 1.1的。

[TousakaRin]

http 默认是连接池，broken的时候应该会把池子里所有的连接都关掉，是不是出现反复broken的现象了

[guodongxiaren]

http 默认是连接池，broken的时候应该会把池子里所有的连接都关掉，是不是出现反复broken的现象了

我们只有一个下游地址。想问一下，brpc所谓的HTTP链接池指的是一个远程ip端口是一个连接，多个下游组成池。还是一个远程ip和端口的时候也会自动建立多个连接？

@TousakaRin
@gydong
@jamesge

[TousakaRin]

http 默认是连接池，broken的时候应该会把池子里所有的连接都关掉，是不是出现反复broken的现象了

我们只有一个下游地址。想问一下，brpc所谓的HTTP链接池指的是一个远程ip端口是一个连接，多个下游组成池。还是一个远程ip和端口的时候也会自动建立多个连接？

@TousakaRin
@gydong
@jamesge

一个远程ip和端口的时候也会自动建立多个连接，连接池的最大连接数量可以通过 max_connection_pool_size 配置

[guodongxiaren]

@TousakaRin 能通过改成 single 单链接的方式解决吗？我试了一下CallMethod（异步调用）会core。。

[TousakaRin]

@TousakaRin 能通过改成 single 单链接的方式解决吗？我试了一下CallMethod（异步调用）会core。。

一个方式是修改max_connection_pool_size ，将连接池的大小改小，这个改动是全局的。
一定要用単连接的话可能需要把协议换成http2.0或者baidu_std，http1.1用单连接不就是等价于同步顺序发送么

[rebornfz]

@guodongxiaren 老哥解决了吗？ 我在一个server里需要用到client来发送和下载图片，qps高一点的时候也遇到了这个情况。

[guoliushui]

在高qps下，我也遇到了这个问题，辛苦有进展后在这里同步下

[rebornfz]

在高qps下，我也遇到了这个问题，辛苦有进展后在这里同步下
我是因为用bthread并发下载导致的（文档里说了不要用bthread并发下载），改成异步就好了

[serverglen]

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

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

@yinqiwen
你用的是单链接吧，改成链接池可能会好很多。

[guodongxiaren]

这个问题的应该是使用bRPC自带的压测工具（rpc_replay、rpc_press)自身存在的bug导致，仅影响压测，线上正常服务应该不会出现问题。原因是压测工具随着时间推移，qps变得不均匀，导致瞬时qps远超过设定值。该问题在2022年已经被FIX。参考：
#1763
#1910
如果有其他bRPC使用者在压测时也遇到类似问题，可以更新到最新版的rpc_replay和rpc_press。
若遇到在正常线上服务时，出现同样qps一开始能正常服务，但经过一段时间后服务出现异常，可以再建新的issue讨论。