关于性能测试中LR的pacing time设置的相关实验

最近项目中遇到相关性能测试不同方法产生的争议，我这就这个问题在测试环境做了个实验，得出一些指标数据间的有趣关系，供大家讨论学习：

预备知识点：

业界有个TPS ,ART和实际并发量三者间的模拟换算公式：U实际并发量=TPS*ART均值

LR有个.net4.0的计数器Request Current能反应实际的测试过程中实际的PV/s量

设置迭代pacing time情况：

请求用户数：15;     pacing time:3s;   理论PV：15/3=5;

TPS:3.4;  ART：1.4   Request Current:4.6  U并发=TPS*ART=3.4*1.4=4.76

请求用户数：75;     pacing time:15s;   理论PV：75/15=5;

TPS:4.5;  ART：1.5   Request Current:6.6  U并发=TPS*ART=4.5*1.5=6.75

请求用户数：100;    pacing time:20s;   理论PV：100/20=5;

TPS:4.5;  ART：1.6   Request Current:6.9  U并发=TPS*ART=4.5*1.5=7.2

1.从上面的数据可以看出实际的Request Current（实际PV/s量）几乎接近实际的并发量,而在有pacing time情况下理论PV和实际PV是随着模拟请求用户数的变化两者的差别变化也是较大，有交集但不同步变化，这个方式不可以预见实际并发量，只能通过测试结果来判断大概的实际并发量，但可以很好的控制模拟请求。

无思考时间和无迭代pacing time情况：

请求用户数：5;       pacing time:无;   理论PV：5;

TPS:3.56;  ART：1.4   Request Current:4.75  U并发=TPS*ART=3.56*1.4=4.98

请求用户数：10;      pacing time:无;   理论PV：10;

TPS:7.69;  ART1.3：   Request Current:9.4   U并发=TPS*ART=7.69*1.3=9.99

请求用户数：15;      pacing time:无;   理论PV：15;

TPS:8.4;  ART：1.7    Request Current:14.4   U并发=TPS*ART=8.4*1.7=14.28

2.从上面的数据可以看出实际的Request Current（实际PV/s量）几乎接近实际的并发量,并且在无pacing time和思考时间情况下理论PV和实际PV和实际并发量几乎同步保持一致（我们目前大多数情况采用的都是这个方式压测）。

这里只针对一个transaction对应一个URL请求的情况，特别是接口类的。

其实两个方法都是性能测试中针对不同测试目的而使用的，各有特点。