brpc
brpc copied to clipboard
apache
rr 模式下，qps 不变，rpc 下游节点增多时，平均耗时和99线耗时明显上升
实现了基于 length + body 的自定义协议，使用 rpc press 压测发现，下游只有一个节点时，时耗稳定并且耗时很小，如果增加下游节点（使用 rr 模式），耗时99线明显上升。
下游节点机器、性能、网络均大致相同，正常情况下处理时耗较短，并且耗时高的 ip 均匀分布。
以下是 1 个下游节点的测试情况：
2022/07/04-15:38:47 sent:3001 success:3002 error:0 total_error:0 total_sent:261105
2022/07/04-15:38:48 sent:3001 success:3001 error:0 total_error:0 total_sent:264106
2022/07/04-15:38:49 sent:3002 success:3001 error:0 total_error:0 total_sent:267108
2022/07/04-15:38:50 sent:3001 success:3001 error:0 total_error:0 total_sent:270109
[Latency]
avg 428 us
50% 408 us
70% 448 us
90% 589 us
95% 656 us
97% 693 us
99% 788 us
99.9% 3003 us
99.99% 3833 us
max 3860 us
以下是 26 个下游节点的测试情况：（平均值和 99 线上升明显）
2022/07/04-15:36:32 sent:3000 success:2998 error:3 total_error:3 total_sent:138053
2022/07/04-15:36:33 sent:3003 success:3001 error:0 total_error:3 total_sent:141056
2022/07/04-15:36:34 sent:3000 success:3001 error:0 total_error:3 total_sent:144056
2022/07/04-15:36:35 sent:3001 success:3002 error:0 total_error:3 total_sent:147057
2022/07/04-15:36:36 sent:3001 success:3001 error:0 total_error:3 total_sent:150058
[Latency]
avg 4793 us
50% 8525 us
70% 8744 us
90% 8847 us
95% 8894 us
97% 8999 us
99% 9361 us
99.9% 10528 us
99.99% 30792 us
max 48065 us
请问有哪些可能的原因呢？
这个是客户端的延迟数据对吧，服务端延迟怎么样呢？先排除是服务端的问题哈。 另外客户端网络情况如何，客户端机器的网卡有被打满吗？如果同时启动 26个下游 和 1个下游 的两个进程，1个下游的进程还能保持低延迟吗？
@lorinlee 是客户端延迟数据，服务端延迟基本都在1ms左右，服务端都是万兆网卡，请求基本在200B以内，没有打满。
另外同时启动两个测试，一个连26个下游，一个只连一个下游，还是一样的结果。一个下游的测试耗时比较低，多个下游的测试耗时明显高出很多。
请问可能还有哪些原因呢
@lorinlee 是客户端延迟数据，服务端延迟基本都在1ms左右，服务端都是万兆网卡，请求基本在200B以内，没有打满。
另外同时启动两个测试，一个连26个下游，一个只连一个下游，还是一样的结果。一个下游的测试耗时比较低，多个下游的测试耗时明显高出很多。
请问可能还有哪些原因呢
用的是什么连接方式？qps大约多少？网络的rtt大约多少？
@lorinlee 试过la模式，耗时情况好很多。
但是，在 la 模式下把发给下游的ip和请求数量列出来了
发现每次测试刚开始的时候，请求分布比较均匀，测试到后面（约1分钟后），请求都大量集中在一个节点上，并且每次测试请求集中的节点都不是同一个下游节点，看起来像随机的，请求集中的节点能收到几万个请求，而其他节点只能收到几十个请求
在 rr 模式下，测试请求均匀分布在下游所有节点上
@lorinlee 这里是下游多节点，random模型的测试情况：
[Latency] avg 4754 us 50% 403 us 70% 3763 us 90% 15567 us 95% 24327 us 97% 32290 us 99% 39459 us 99.9% 40148 us 99.99% 40715 us max 41832 us
也是耗时比较高，下游请求均匀分布。T.T
@wwbmmm 现在测试了26个节点 3000*26 qps的情况，rr模式，耗时情况确实好很多！！！ 很接近单节点 3000 qps的情况。
另外还测试了 单节点 100 qps，耗时情况也非常好，响应基本都在1ms左右。
这个可能是什么原因呢
@wwbmmm 下游qps越高，耗时情况越好，并且 rpc_press 工具的 thread_num 参数越小，耗时情况也越好。
下面针对线程数的一个测试，下游26个节点，rr模式：
qps=78000 thread_num=1，一个线程最多64000qps，这个耗时情况比较好
==================================================
2022/07/07-10:36:03 sent:64592 success:64594 error:0 total_error:0 total_sent:18674682
[Latency]
avg 491 us
50% 500 us
70% 506 us
90% 519 us
95% 528 us
97% 533 us
99% 542 us
99.9% 762 us
99.99% 3710 us
max 11915 us
qps=78000 thread_num=0 rpc_press决定线程数，可以达到78000qps，这个耗时情况不是很理想，但是也比 26个节点总共3000 qps 好非常多了
==================================================
2022/07/07-10:38:52 sent:78015 success:78362 error:0 total_error:0 total_sent:3900746
[Latency]
avg 1015 us
50% 744 us
70% 1027 us
90% 1558 us
95% 1869 us
97% 2198 us
99% 4045 us
99.9% 24466 us
99.99% 26290 us
max 27601 us
rpc_press是最新版吗？如果不是，建议更新到包含这个PR的版本试试：https://github.com/apache/incubator-brpc/pull/1763
@wwbmmm 我们之前用的代码是 0.9.7 版本。我们使用了最新的 master 分支代码，并把我们实现的协议 patch 上去后，再测试发现：
- 使用新版本，thread_num 设置 1， 3000qps 26个下游节点，耗时很低，和 3000 qps 一个节点情况相当比旧版本测试结果好很多。
- 使用旧版本，thread_num 设置 1，如果设置 qps=0，相当于同步发送，3000qps 26个下游节点，速度可到3000qps，95线时耗小于1ms。
- 使用新旧版本，thread_num 设置 2 或者 3，3000qps 26个下游节点，耗时情况不理想，50线和99线有明显升高。
- bthread_usage 监控值并不高，离 bthread_count 还有空余。
这个问题我们在线上服务中遇到了，然后使用了 rpc_press 发现和线上情况类似。但是看 #1763 如果理解没错的话应该是优化 rpc_press 发送时间间隔，以稳定发送 qps，请问为什么还会让耗时情况变好呢？
另外，我们线上服务是使用异步请求，多线程发送，bthread_usage 也并不高，有空闲
旧版rpc_press的问题是发送qps不稳定，有时瞬间发送大量请求，然后又空闲一段时间没有请求。 我猜测你们线上服务可能也是这种情况。 再加上请求被分散给了26个下游结点，那每个下游可能空闲时间更长，空闲期间线程可能被操作系统挂起，或者内存等资源被换出，再次收到请求时就得重新唤醒，导致长尾耗时变多。