运行时的Pacing设置主要影响什么?
Pacing主要用来设置重复迭代脚本的间隔时间。共有三种方法：
A:上次迭代结束后立刻开始、
B:上次迭代结束后等待固定时间、
C:按固定或随机的时间间隔开始执行新的迭代。----常用
根据实际需要设置迭代即可。通常，没有时间间隔会产生更大的压力。
笔者：很多人在使用LR时会忽略此选项，但对LR有深入理解的人，会经常使用该配置。测试场景：100个并发用户达到100TPS的处理能力，重点验证并发用户，也就是每个并发用户要控制在1s内请求一次，达到100TPS的目标；做负载测试的时候，可以逐步加大并发用户，来查看系统的最大并发能力。之前笔者也一直喜欢用LR的目标模式，就是设置100个用户，目标为100TPS，但这边有个问题，是否达到100TPS时候，真正使用了100个用户呢？这个不是一定的，以为1s是个时间段，里面有1000ms，如果你接口性能足够的好的话，你用10个并发用户都能达到100TPS的目标，以为每个用户1s中做了十次请求（这个是由于系统响应很快），虽然达到了100TPS的目标，但并不是实际的并发用户数量，所以，才会有笔者上面所说的使用的设置。
举个例子来说：设置后（上面的C情况），如果1个用户的请求在200ms内系统就返回了响应，那该用户的在下次迭代开始就是休息800ms,也就是在1s内，达到100TPS时，是每个用户都请求了一次。由于系统的响应时间我们没法控制，所在LR的高级指出就体现了，LR会自动的根据响应时间来调整每次迭代，从而满足你的设置要求。
注：以上场景存在疑问的或者关于性能方面的细节东西，不懂的自己百度下。这里不再详述。
注：转载需注明出处及作者。
