Yiming

@Mensu 请问我的为什么没有catalog呢，我找了好久，而且把整个项目重新布置了一下还是不行。。。 不是太懂前端的东西，能帮我看一下吗。。。http://leiym.com/2016/12/19/effective_C++/ 主页下面有我的github地址，可以在里面找到博客项目。

@Voleking 太感谢啦~

@lorinlee 是客户端延迟数据，服务端延迟基本都在1ms左右，服务端都是万兆网卡，请求基本在200B以内，没有打满。 另外同时启动两个测试，一个连26个下游，一个只连一个下游，还是一样的结果。一个下游的测试耗时比较低，多个下游的测试耗时明显高出很多。 请问可能还有哪些原因呢

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

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

@wwbmmm 现在测试了26个节点 3000*26 qps的情况，rr模式，耗时情况确实好很多！！！ 很接近单节点 3000 qps的情况。 另外还测试了 单节点 100 qps，耗时情况也非常好，响应基本都在1ms左右。 这个可能是什么原因呢

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

@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%...

@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线有明显升高。...