性能测试结果分析

测试场景设置：

首先将脚本放入场景，分配设置Vuser数量为10、15、50和75，分四次运行，每次持续5分钟（这里设置持续5分钟，并不是说每次场景只需要运行5分钟而已，而是为了快速采集部分演示数据，实际不同的场景脚本需要持续多少时间，根据业务需求而定），收集并发用户数、响应时间和通过事务量来进行数据曲线的变化的分析。此处省略了LR结果图形截图，让我们直接来看整理后的数据。（监控数据暂不纳入其中）

通过整理后的统计数据可以看出（以并发用户数从10增加到15 为栗）：

1. 用户并发量增加了约为1.5倍；

2. 平均响应时间从0.227S增加到了0.297S，增加约为1.3倍；

3. 平均TPS（TPS采用的计算方法为 TPS=并发用户数*1/平均响应时间）由约为44增加到了约为51，约增加了1.16倍；

4. 事务通过量由652增加到了907，约增加为1.4倍。

由归纳整理后的数据，可以做出以下分析：

1. 如果当我们系统的TPS在没有达到最大值之前，用户量增加1.5倍，那么通过事务总量也应该增加1.5倍，但是实际情况是通过的事务总量增量了1.4倍；

2. 如果TPS在10个并发用户的时候已经是最大值了，那么并发用户增加1.5倍，响应时间应该增加1.5倍，事务通过量无明显增加或者减少，实际上我们的平均响应时间增加了约为1.3倍，事务通过总量增加了约为1.4倍。

通过以上分析方法，我们可以确定：

1. 在并发用户为10的时候，系统的TPS还是有提升空间的。

2. 同理可得，当并发用户达到15的时候TPS已经不会继续提升了，但是不代表系统响应就很糟糕了，因为当TPS到达50的时候平均响应时间也只有1S而已。

3. 当用户达到75时，TPS已经不会继续提升了且平均响应时间达到11.238S。接下去我们需要运用相同的方法，细化此时间段的测试，结合其他监控数据去定位系统最优可承受的并发用户数。

综上所述，我们所做的一切分析都是基于列表中数据展开的，列表经过处理的数据是来自性能测试工具LR的原始统计数据。由此可见，分析方法没有本质区别，主要区别在于我们如何获取要分析的数据、分析哪些数据。选择数据的时候也并非所有场景数据都可以纳入分析范畴，要选择整个场景运行稳定的数据进行相关分析。将有效数据归纳整合成数据走势图，根据数据走势运用理论的思想分析数据，就是本篇的核心所在。