Loadrunner性能指标分析
1、Transation Sunmmary（事务综述）
对事务进行综合分析是性能分析的第一步，通过分析测试时间内用户事务的成功与失败情况，可以直接判断出系统是否运行正常。
2、Average Transaciton Response Time（事务平均响应时间）
“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。根据该图，可以定位出现性能问题的转折点。
说明：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
当事务响应时间的曲线开始由缓慢上升，然后处于平衡，最后慢慢下降，可能情况：
1）曲线图持续上升，表明系统的处理能力在下降，事务的响应时间变长；
2）持续平衡，表明并发用户数达到一定数量，再多请求也可能接受不了，等待；
3）当事务的响应时间在下降，表明并发用户的数量在慢慢减少，事务的请求数也在减少。
如果系统没有出现下降，但响应时间越来越长，直到系统瘫痪，引起原因可能如下:
1）程序中用户数连接未做限制，导致请求数不断上升，响应时间不断变长；
2）内存泄露。
3、Transactions per Second（每秒通过事务数，简写TPS）
“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
说明：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。TPS值，越大说明系统处理能力越强。
4、Total Transactions per Second（每秒通过事务总数）
“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。该曲线走向和TPS曲线走向一致。
5、Transaction Performance Sunmmary（事务性能摘要）
“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
说明：重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
6、Transaction Response Time Under Load（事务响应时间与负载）
“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。
7、Transaction Response Time(Percentile)（事务响应时间(百分比)）
“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。
说明：主要观察，在给定时间的范围内完成事务的百分比
参考值： 10%的TRT（P）<=5s、50%的TRT（P）<=5s、90%的TRT（P）<=5s
8、Transaction Response Time(Distribution)（事务响应时间(分布)）
“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最
大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。
说明：主要观察，大多数事务的响应时间
参考值：TRT（D）<=5s
Analysis分析器
Analysis Summary概要部分：
Statistic Summary统计部分：
事务统计部分：
第一行统计场景运行时所有事务通过、失败、停止的数量。而表格里则是显示了所有事务执行时的详细信息：
1）transaction name（事务名）；2）minimum（事务运行的最短时间）；3）average（事务运行的平均时间）；4）maximum（事务运行的最长时间）；
5）std.deviation（标准方差）：方差描述一组数据偏离其平均值的情况，方差值越大，说明这组数据就越离散，波动性也就越强；反之，则说明这组数据就越聚合，波动性也就越小；
6）90 percent：在controller运行场景时，并不会显示这个值，因为它是对整个一系列数据统计的结果。表示一个事务在执行过程中的90%所花费的时间，比如，一个事务执行了100次，对这100次事务响应时间进行升序排序，第90%即90次事务运行时间；
7）pass（通过的事务个数）；8）fail（失败的事务个数）；9）stop（停止的事务个数）：在执行场景时，若用户手工停止场景的执行，事务没有自己的状态，那么就是停止状态。
注：事务的通过率一定要大于95%，也即失败率应该小于5%，因为如果事务失败率过高，就说明客户在使用系统时很容易出现错误，这样无论事务响应时间多么短也是不符合要求的，因为客户最基本的需求都没有被满足，功能都不能正确的处理，那么更无法谈性能了。
2、Average Transaciton Response Time（事务平均响应时间）
“事务平均响应时间”显示的是测试场景运行期间的每一秒内事务执行所用的平均时间，通过它可以分析测试场景运行期间应用系统的性能走向。根据该图，可以定位出现性能问题的转折点。
说明：随着测试时间的变化，系统处理事务的速度开始逐渐变慢，这说明应用系统随着投产时间的变化，整体性能将会有下降的趋势。
当事务响应时间的曲线开始由缓慢上升，然后处于平衡，最后慢慢下降，可能情况：
1）曲线图持续上升，表明系统的处理能力在下降，事务的响应时间变长；
2）持续平衡，表明并发用户数达到一定数量，再多请求也可能接受不了，等待；
3）当事务的响应时间在下降，表明并发用户的数量在慢慢减少，事务的请求数也在减少。
如果系统没有出现下降，但响应时间越来越长，直到系统瘫痪，引起原因可能如下:
1）程序中用户数连接未做限制，导致请求数不断上升，响应时间不断变长；
2）内存泄露。
3、Transactions per Second（每秒通过事务数，简写TPS）
“每秒通过事务数/TPS”显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，使考查系统性能的一个重要参数。通过它可以确定系统在任何给定时刻的时间事务负载。分析TPS主要是看曲线的性能走向。将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。
说明：当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。TPS值，越大说明系统处理能力越强。
4、Total Transactions per Second（每秒通过事务总数）
“每秒通过事务总数”显示在场景运行时，在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。该曲线走向和TPS曲线走向一致。
5、Transaction Performance Sunmmary（事务性能摘要）
“事务性能摘要”显示方案中所有事务的最小、最大和平均执行时间，可以直接判断响应时间是否符合用户的要求。
说明：重点关注事务的平均和最大执行时间，如果其范围不在用户可以接受的时间范围内，需要进行原因分析。
6、Transaction Response Time Under Load（事务响应时间与负载）
“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合，通过它可以看出在任一时间点事务响应时间与用户数目的关系，从而掌握系统在用户并发方面的性能数据，为扩展用户系统提供参考。此图可以查看虚拟用户负载对执行时间的总体影响，对分析具有渐变负载的测试场景比较有用。
7、Transaction Response Time(Percentile)（事务响应时间(百分比)）
“事务响应时间(百分比)”是根据测试结果进行分析而得到的综合分析图，也就是工具通过一些统计分析方法间接得到的图表。通过它可以分析在给定事务响应时间范围内能执行的事务百分比。
说明：主要观察，在给定时间的范围内完成事务的百分比
参考值： 10%的TRT（P）<=5s、50%的TRT（P）<=5s、90%的TRT（P）<=5s
8、Transaction Response Time(Distribution)（事务响应时间(分布)）
“事务响应时间(分布)”显示在场景运行过程中，事务执行所用时间的分布，通过它可以了解测试过程中不同响应时间的事务数量。如果系统预先定义了相关事务可以接受的最小和最
大事务响应时间，则可以使用此图确定服务器性能是否在可以接受的范围内。
说明：主要观察，大多数事务的响应时间
参考值：TRT（D）<=5s
Analysis分析器
Analysis Summary概要部分：
Statistic Summary统计部分：
事务统计部分：
第一行统计场景运行时所有事务通过、失败、停止的数量。而表格里则是显示了所有事务执行时的详细信息：
1）transaction name（事务名）；2）minimum（事务运行的最短时间）；3）average（事务运行的平均时间）；4）maximum（事务运行的最长时间）；
5）std.deviation（标准方差）：方差描述一组数据偏离其平均值的情况，方差值越大，说明这组数据就越离散，波动性也就越强；反之，则说明这组数据就越聚合，波动性也就越小；
6）90 percent：在controller运行场景时，并不会显示这个值，因为它是对整个一系列数据统计的结果。表示一个事务在执行过程中的90%所花费的时间，比如，一个事务执行了100次，对这100次事务响应时间进行升序排序，第90%即90次事务运行时间；
7）pass（通过的事务个数）；8）fail（失败的事务个数）；9）stop（停止的事务个数）：在执行场景时，若用户手工停止场景的执行，事务没有自己的状态，那么就是停止状态。
注：事务的通过率一定要大于95%，也即失败率应该小于5%，因为如果事务失败率过高，就说明客户在使用系统时很容易出现错误，这样无论事务响应时间多么短也是不符合要求的，因为客户最基本的需求都没有被满足，功能都不能正确的处理，那么更无法谈性能了。