平均耗时普遍比最短耗时还要小

[link1st]

平均耗时普遍比最短耗时还要小

[eashme]

可以给一下计算公式吗，代码中我看到有 除一个协程数, 我把协程数乘回去刚好符合自己的预测

[link1st]

本项目是并发压测的
QPS = 服务器每秒钟处理请求数量 (req/sec 请求数/秒)

定义：单个协程耗时T, 所有协程压测总时间 sumT,协程数 n

如果:只有一个协程，假设接口耗时为 2毫秒，每个协程请求了10次接口，每个协程耗总耗时2*10=20毫秒,sumT=20
QPS = 10/20*1000=500

如果:只有十个协程，假设接口耗时为 2毫秒,每个协程请求了10次接口，每个协程耗总耗时2*10=20毫秒,sumT=20*10=200
QPS = 100/(200/10)*1000=5000

上诉两个示例现实中总耗时都是20毫秒，示例二 请求了100次接口，QPS应该为 示例一 的10倍，所以示例二的实际总QPS为5000

除以协程数的意义是，sumT是所有协程耗时总和

[eashme]

好的，明白了，谢啦

[yyltesting]

QPS = 100/(200/10)*1000=5000

你的并发数每次都是固定的并发数去计算的 应该是动态实际请求的并发协程数去计算吧 用chanIDLen才对吧？

[link1st]

QPS = 100/(200/10)*1000=5000

你的并发数每次都是固定的并发数去计算的 应该是动态实际请求的并发协程数去计算吧 用chanIDLen才对吧？

@yyltesting 目前使用的是固定的并发数计算的

• 如果是使用动态协程数 chanIDLen 计算QPS，会导致QPS比较高

程序是先启动协程，每个协程开始并发请求服务端，类似于"跑马"效果，如果使用 动态协程数，最早的 QPS 是就会使用跑马最快的一个或者是几个计算QPS
会导致平均耗时很低(跑马中最快的)，QPS 会虚高

• QPS 应该是压测一段时间，并发数一定 QPS 稳定在一个数值的访问才是在该并发下服务端的实际QPS
• 所以，这里使用的是固定并发数计算的更合理