rr 模式下，qps 不变，rpc 下游节点增多时，平均耗时和99线耗时明显上升

[Missmiaom]

实现了基于 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

请问有哪些可能的原因呢？

[lorinlee]

这个是客户端的延迟数据对吧，服务端延迟怎么样呢？先排除是服务端的问题哈。
另外客户端网络情况如何，客户端机器的网卡有被打满吗？如果同时启动 26个下游 和 1个下游 的两个进程，1个下游的进程还能保持低延迟吗？

[Missmiaom]

@lorinlee 是客户端延迟数据，服务端延迟基本都在1ms左右，服务端都是万兆网卡，请求基本在200B以内，没有打满。

另外同时启动两个测试，一个连26个下游，一个只连一个下游，还是一样的结果。一个下游的测试耗时比较低，多个下游的测试耗时明显高出很多。

请问可能还有哪些原因呢

[cdjingit]

@lorinlee 是客户端延迟数据，服务端延迟基本都在1ms左右，服务端都是万兆网卡，请求基本在200B以内，没有打满。

另外同时启动两个测试，一个连26个下游，一个只连一个下游，还是一样的结果。一个下游的测试耗时比较低，多个下游的测试耗时明显高出很多。

请问可能还有哪些原因呢

用的是什么连接方式？qps大约多少？网络的rtt大约多少？

[Missmiaom]

@cdjingit 使用的是单连接模式，qps 保持在3000，测试程序和下游节点都在同一机房，网络的rtt在0.05ms左右

[lorinlee]

@Missmiaom 有试过使用其他的lb策略吗，延迟是否有变化呢

[Missmiaom]

@lorinlee 试过la模式，耗时情况好很多。

但是，在 la 模式下把发给下游的ip和请求数量列出来了

发现每次测试刚开始的时候，请求分布比较均匀，测试到后面（约1分钟后），请求都大量集中在一个节点上，并且每次测试请求集中的节点都不是同一个下游节点，看起来像随机的，请求集中的节点能收到几万个请求，而其他节点只能收到几十个请求

在 rr 模式下，测试请求均匀分布在下游所有节点上

[lorinlee]

@Missmiaom 有试过random吗，方便试下看延迟情况如何呢

[Missmiaom]

@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]

保持下游的qps一致试试，比如一个下游的时候3000qps，26个下游的时候3000*26 qps试试。

[Missmiaom]

@wwbmmm 现在测试了26个节点 3000*26 qps的情况，rr模式，耗时情况确实好很多！！！ 很接近单节点 3000 qps的情况。

另外还测试了 单节点 100 qps，耗时情况也非常好，响应基本都在1ms左右。

这个可能是什么原因呢

[wwbmmm]

下游26个节点，是在同一台机器上的吗？

[Missmiaom]

@wwbmmm 不是噢，4个节点一个物理机

[Missmiaom]

@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

[wwbmmm]

rpc_press是最新版吗？如果不是，建议更新到包含这个PR的版本试试：#1763

[Missmiaom]

@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 也并不高，有空闲

[wwbmmm]

旧版rpc_press的问题是发送qps不稳定，有时瞬间发送大量请求，然后又空闲一段时间没有请求。
我猜测你们线上服务可能也是这种情况。
再加上请求被分散给了26个下游结点，那每个下游可能空闲时间更长，空闲期间线程可能被操作系统挂起，或者内存等资源被换出，再次收到请求时就得重新唤醒，导致长尾耗时变多。

[wwbmmm]

还有可能是tcp_autocorking导致的，
把/proc/sys/net/ipv4/tcp_autocorking的值改成0试试