MapleLove2014 opened a new issue, #2357: URL: https://github.com/apache/brpc/issues/2357
**Describe the bug (描述bug)** 压测brpc thrift接口时单个压测进程最多只能压8并发，超过后耗时飙升。 以并发数8为例，压测程序(golang语言编写)逻辑为： 1. 初始化8个连接的连接池，即有8个client（client用的是golang thrift的原生client） 2. 每次循环并发从每个连接中发送rpc请求，即每次循环并发请求8次 3. 等并发的8次请求全部返回后继续下一次循环 4. 每秒统计一次这一秒内所有请求的平均耗时，P99，P999等 brpc thrift服务端接口主要逻辑如下： 1. 计算overhead（网络+序列化+反序列化），即：进到服务端接口时间 - 压测程序请求时间 2. 对请求数据进行解析处理，耗时大概6ms 3. 对任务拆成25个子任务，并发执行（bthread_start_background），执行逻辑为 bthread_usleep(1000 * 50); 通过sleep 50ms模仿真实的任务处理时间 4. 然后bthread_join，等待25个任务执行完成 5. 统计耗时，结束 服务器情况： CPU: Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz * 2 共40核 内存: DDR4_16G*8[2400] 硬盘: HDD_600G*8[SAS_2.5_10K] 以并发数8为例，压测结果如下： 2023/08/15 14:35:14 AVG[60ms],P75[ 61ms],P95[ 63ms],P99[ 64ms],P999[ 64ms],ERRORS[0] 2023/08/15 14:35:15 AVG[60ms],P75[ 61ms],P95[ 62ms],P99[ 63ms],P999[ 63ms],ERRORS[0] 2023/08/15 14:35:16 AVG[60ms],P75[ 61ms],P95[ 62ms],P99[ 63ms],P999[ 63ms],ERRORS[0] 2023/08/15 14:35:17 AVG[60ms],P75[ 61ms],P95[ 62ms],P99[ 62ms],P999[ 62ms],ERRORS[0] 2023/08/15 14:35:18 AVG[60ms],P75[ 61ms],P95[ 62ms],P99[ 63ms],P999[ 63ms],ERRORS[0] 2023/08/15 14:35:19 AVG[60ms],P75[ 61ms],P95[ 62ms],P99[ 62ms],P999[ 62ms],ERRORS[0] 2023/08/15 14:35:20 AVG[59ms],P75[ 60ms],P95[ 61ms],P99[ 61ms],P999[ 61ms],ERRORS[0] 2023/08/15 14:35:21 AVG[59ms],P75[ 61ms],P95[ 61ms],P99[ 62ms],P999[ 62ms],ERRORS[0] 2023/08/15 14:35:22 AVG[60ms],P75[ 61ms],P95[ 62ms],P99[ 62ms],P999[ 62ms],ERRORS[0] 2023/08/15 14:35:23 AVG[60ms],P75[ 61ms],P95[ 62ms],P99[ 63ms],P999[ 63ms],ERRORS[0] 耗时基本在63ms左右，overhead P99为2ms符合预期。在brpc的网页监控上查看符合预期： <img width="460" alt="CleanShot 2023-08-15 at 14 38 19@2x" src="https://github.com/apache/brpc/assets/34023519/6d9d9d7d-eab9-48a6-a82a-7930d3c31d00";> 但是只要把并发数+1，压9个并发，耗时就开始飙升，压测结果为： 2023/08/15 14:41:43 AVG[66ms],P75[ 61ms],P95[116ms],P99[117ms],P999[117ms],ERRORS[0] 2023/08/15 14:41:44 AVG[65ms],P75[ 61ms],P95[115ms],P99[117ms],P999[117ms],ERRORS[0] 2023/08/15 14:41:45 AVG[66ms],P75[ 61ms],P95[116ms],P99[117ms],P999[117ms],ERRORS[0] 2023/08/15 14:41:46 AVG[67ms],P75[ 62ms],P95[117ms],P99[119ms],P999[119ms],ERRORS[0] 2023/08/15 14:41:47 AVG[65ms],P75[ 62ms],P95[116ms],P99[118ms],P999[118ms],ERRORS[0] 2023/08/15 14:41:48 AVG[66ms],P75[ 61ms],P95[116ms],P99[117ms],P999[117ms],ERRORS[0] 2023/08/15 14:41:49 AVG[65ms],P75[ 62ms],P95[116ms],P99[117ms],P999[117ms],ERRORS[0] 2023/08/15 14:41:50 AVG[65ms],P75[ 61ms],P95[114ms],P99[116ms],P999[116ms],ERRORS[0] 2023/08/15 14:41:51 AVG[66ms],P75[ 61ms],P95[116ms],P99[118ms],P999[118ms],ERRORS[0] 2023/08/15 14:41:52 AVG[66ms],P75[ 62ms],P95[116ms],P99[119ms],P999[119ms],ERRORS[0] P99耗时从之前的63ms涨到119ms，大概涨了一倍。从brpc的监控网页看并发数依然是8: <img width="538" alt="CleanShot 2023-08-15 at 14 43 44@2x" src="https://github.com/apache/brpc/assets/34023519/65cbbca6-6e0e-46de-9587-a2c7b9b6b560";> 看overhead耗时P99为62ms。对于这个现象，我的理解是：9个并发请求，但服务端只能并发处理8个，耗时62ms。导致有一个请求要等62ms后才能被服务端处理（通过overhead也能验证），而压测程序统计的是9个并发请求的总处理事件，差不多为62*2=124ms。 并发数为8或者为9时，服务端CPU使用率非常低%3（毕竟sleep也不需要很多cpu）。io同样很轻，iostat结果： Linux 4.9.2-3.0.0.std7b.el7.6.x86_64 2023年08月15日 _x86_64_ (40 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 0.67 0.00 0.18 0.00 0.00 99.15 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 4.20 11.65 355.23 11003668 335525042 dm-0 2.76 0.98 18.20 929005 17188772 dm-1 0.00 0.00 0.00 936 0 dm-2 4.60 10.66 336.80 10070533 318115844 接着更有意思的是，我在跑压测程序（以8并发为例）的机器上再起一个压测进程同样压8并发，这时brpc的监控页面上正常显示出并发为16： <img width="941" alt="CleanShot 2023-08-15 at 14 54 39@2x" src="https://github.com/apache/brpc/assets/34023519/b56d9ee4-8e56-4fa8-a170-fc3ef5210938";> 这2个压测进程的压测结果一致为： 2023/08/15 14:54:48 AVG[60ms],P75[ 61ms],P95[ 62ms],P99[ 63ms],P999[ 63ms],ERRORS[0] 2023/08/15 14:54:49 AVG[60ms],P75[ 61ms],P95[ 62ms],P99[ 62ms],P999[ 63ms],ERRORS[0] 2023/08/15 14:54:50 AVG[60ms],P75[ 62ms],P95[ 62ms],P99[ 62ms],P999[ 63ms],ERRORS[0] 2023/08/15 14:54:51 AVG[60ms],P75[ 61ms],P95[ 62ms],P99[ 63ms],P999[ 63ms],ERRORS[0] 2023/08/15 14:54:52 AVG[61ms],P75[ 62ms],P95[ 62ms],P99[ 63ms],P999[ 63ms],ERRORS[0] 2023/08/15 14:54:53 AVG[60ms],P75[ 62ms],P95[ 62ms],P99[ 63ms],P999[ 63ms],ERRORS[0] 2023/08/15 14:54:54 AVG[60ms],P75[ 61ms],P95[ 62ms],P99[ 63ms],P999[ 63ms],ERRORS[0] 通过上述现象可以观察出，这个服务端8个并发的限制貌似还是基于进程级别的？所以我这里非常纳闷，希望辛苦brpc社区的大佬们帮忙看看，是我使用的姿势有问题，还是有什么bug。 brpc服务端的主要参数如下： max_concurrency: unlimited ServerOptions.num_threads=40 connection_type: default **Versions (各种版本)** OS: Linux 4.9.2-3.0.0.std7b.el7.6.x86_64 gcc: 4.8 brpc: 0.9.5 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@brpc.apache.org For additional commands, e-mail: dev-h...@brpc.apache.org
