【loadrunner】实践中浅析集合点和思考时间对TPS的影响

问题背景：使用Loadrunner加压的方式与开发使用开发的工具加压的方式，在1000并发的时候TPS获取的值差距非常大，并且Loadrunner加压的方式TPS无法递增。
实际原因：总体分析，猜想可能产生的原因：
1、客户端发送请求慢（设置思考时间和迭代时间导致）；
2、程序处理能力；
3、网络问题。
为了定位问题，先从这三方面出发，开始从最简单的问题排除，顺序为：3->1->2,经过排查，网路问题和客户端请求慢的没问题，以为是程序问题，但是通过开发提供的工具进行测试，发现程序的处理能力是可以的，tps是比预期的还大，为了解除疑惑，能准确定位问题所在，只能重新分析几次，经过多轮测试，发现客户端的脚本中设置或未设置集合点时，影响到客户端发送请求次数，结果中的tps也相差很大，最终确定问题就在“集合点”上。既然是集合点的问题，那就解析一下集合点为什么会产生如此结果，原因很简单，集合点函数在运行场景时，每个虚拟用户都需检查一下集合点的策略设置，如果不满足策略，虚拟用户只能在集合点处于等待状态，直到集合点策略满足后，方可执行下一轮操作，如果虚拟用户发送的请求在服务器程序处理的时间不一致，就会形成较大的时间差等待或超时，所以这本次测试tps无法增加的问题，在设置了集合点函数。
解决方案：如果需要获取某业务的最大处理能力的时候，需要将思考时间和集合点去掉，以保证脚本能够最快的运行，使服务器的处理能力达到最高。但需要注意，持续时间不能过长，服务器得不到暂时的缓冲，我们将会看到内存持续消耗的现象。

反思：性能关键指标的理论依据与现实测试方法和业务应用的结合，是必须并且重要的。