Loadrunner-场景设置以及监控结果分析

一、Controller的基本工作原理：通过1、2、3设置来模拟用户的操作，收集出4的各种信息

二、场景设置一般步骤

• 1、新建场景（Controller）
• 2、添加脚本
• 3、设置Schedule（设置场景运行的策略，主要设置Globle Schedule 这一项）

• 4、添加压力机（可以指定多台windows或者linux压力机产生压力）
  1）添加压力机方法：Scenario - Load Generators
  2）添加的压力机于Controller所在机器在同一网段，把防火墙关了

• 5、设置run time setting
  1）以Controller中的选项为主

• 6、运行观察

三、分析思路：

• 1、分析原则：由外到内，由表到里，层层深入。拆分问题，隔离问题（好比学习一样，把时
  间段分成一片一片的，把零散时间灵活应用起来）。
• 2、 对于一个应用系统，性能开始出现了下降，最直观最直接的表象就是系统的响应时间，
  如果响应时间变长，则系统响应时间就是分析性能的起点。
• 3、 任何一个复杂的系统都可以分为网络和服务器两部分。
• 4、 性能测试不是一蹴而就的，而是贯穿整个性能测试的流程。
• 5、 性能分析调优是一个不断推理不断验证的过程，不断试错，不断改正，打开自己的思维。

四、重点指标：

• 1、TPS（每秒通过事物数，直接反应服务器的处理能力，可理解为地铁进站口刷卡机）
• 2、平均事物响应时间（最直观的指标，可作为突破口）
• 3、每秒连接数（可初步判断是否需要调优连接数配置）
• 4、点击数（直接反应请求数、客户端、网络，点击数出现问题一般为脚本或者网络出现了问题）

五、分析思路模型：

1 、重点关注Transaction Summary （事物概要）模块
（1）平均响应时间：当标准差比较小的时候，选择事物的平均响应时间。
（2）90%响应时间：当标准差比较大的时候，去掉最高最低，取90%响应时间更有
分析价值。
*（3）Std：标准差比较小，则相对比较平稳，标准差比较大时，则表明浮动比较大

分析Web Tour中的Transaction Summary （事物概要），回想前面的内容，最直观的指标就是“平均响应时间”，可把它作为突破口

由图可以看出，check的平均响应时间是最大的，要相对的比较，可以把check作为分析的突破口。

其他事物可以不用分析，根据木桶原理，补最大的缺口。

2、HTTP Responses Summary（HTTP返回状态概要）

（1）HTTP Responses Summary主要统计服务器的返回状态
（2）由图可看出返回都是200的状态码，而且总数8789与Statistics Summary（标准概要）
中的值基本一致，说明大部分请求都是成功的。

** 注意：**
说非200的状态码不一定是错的，需要根据具体业务来分析，比如302、304状
态码也是很正常的，不会影响性能测试结果。但是返回500的状态码的话就是错误的，
说明服务器内部错误。

六、分析过程 重点、重点、、、

接触LR的分析过程：

1、首先来分析running Vusers这项，双击打开

分析：
首先要看坐标图，X轴代表时间，Y轴一般代表指标，这里就是代表模拟用户数。由图可以看出，模拟用户数慢慢增长，然后平稳一段时间，最后再慢慢下降，这是一个合理的过程。假如出现红线那样的坐标图，用户数急速下降，那么很可能就是服务器down掉了。

2、 Error statistics（错误描述统计）

分析：
能进行到这一步说明脚本运行是没问题的了（比如检查点不对这些因素就可以排除掉了）。

最后两行有Faied to connect server 明显可以看出是连接服务器失败了；有两行是timeout提示，这个出现的次数不多，可以不管。

如果要去掉的话可以在Controller中Run-time-Setting设置，把perferences中的HTTP-request connect timeout(sec)、HTTP-request receive timeout(sec)和Step download timeout(sec)的值调大一点。

前面两行初步判断可能是关联出了问题，关联抓不到，可能是服务器返回失败。

得出初步结论：

• （1）连接服务器失败，遭到服务器拒绝，可能是系统出现瓶颈无法及时处理请求
• （2）关联抓不到，可能是服务器返回失败
• （3）timeout提示一般可以不管，如果要去掉的话可以在Controller中Run-time-Setting设置

3 、Error per Second（每秒错误数）

• 每秒错误数图是对每秒出现的错误进行统计，数值越小越好。
• 2-7min过程中错误数明显增加，可以判断系统在这个时间段开始不稳定。

4、Average Transaction Response Time（平均事物响应时间）

每秒内事物执行所用的时间

由图可以看出，到3s后，事物的平均响应时间突然下降。在这里可以大胆地推测，是不是因为服务器非常好，处理事物的能力非常强，所以事物执行的时间很少。

但是联想到上面的每秒错误数的图，在一段时间内每秒错误数都是差不多平稳的，所以说服务器处理事物能力非常好这个结论经不起推敲。

也有可能是处理能力差或者出现大量的连接错误、服务器出现down机等，前面说到，任何一个复杂的系统都可以分为服务器和网络，所以说也有可能是网络的原因。

结论：
（1）服务器出现拒绝连接、出现大量错误或者是服务器down机了
（2）也有可能是网络连接的问题

5、 TPS（每秒通过事物数）

TPS是考查系统性能的一个重要指标，值越高，说明系统处理能力越强

可以看出来，整体的TPS不是很高，说明服务器处理能力有待提高，后续要把TPS提升

6 、Hits per Second（每秒点击数）

虚拟用户每秒向Web服务器提交的Http请求数

总体来看没有啥问题，还是可以。2-5min过程中出现了一些波动，每秒点击数是服务端侧的，

那就应该是脚本或者网络的问题，从前面的分析得知，脚本是没问题的，那就基本可以判断出现波动是因为网络问题导致的。

7、Connections per Second（每秒连接数）

每秒连接数就是每秒中打开的TCP/IP连接数，当连接数到达稳定的时候而事物响应时间增大时，
添加连接数可以使系统性能得到提高。好比一个池塘放水，多开几条沟水会放得越快。

每秒连接数统计新建的连接数和关闭的连接数，可以了解每秒对服务器产生连接的数量，

图中可以看出每秒连接数都是比较低的，可以适当增加连接数来提高系统性能。

七、性能测试流程

过程分析：
（1）性能需求点获取

• 根据客户的需求由客户方提出
• 根据历史数据分析
• 参考历史项目或者其他同行业的项目
• 业内通用规则
• 确实没有数据，那就根据自己来，然后一边分析

（2）测试点的提取，常放在客户常用的、重点的模块和功能上

• 用户常用功能，比如登录
• 数据流转向复杂或频繁的地方
• 发生频率高的地方，比如搜索，提交订单，下单结账。
• 关键程度高的（比如产品经理认为绝对不能出现问题的地方，登录、下单等）
• 资源占用非常严重的
• 关键的接口

（3）测试环境

• 最好能和线上保持一致
• 如果不能那就等比的放大或缩小
• 软件版本应该一致

（4）测试数据

• 铺底数据的准备：是空库还是有数据量。数据量的选择参考线上的数据量进行
  等比的放大或缩小。
• 最好的数据来源于线上的真实数据，因为分布合理
• 如果涉及到保密的数据，注意数据的脱密处理

（5）测试过程

• 性能测试时一个需要不断改进的过程，每一次尽量做得更好，多做一点点以前
  没想到的东西，然后不断积累总结，然后你会发现自己对性能测试有了更深的
  理解

（6）响应时间预估

• 线上监控系统得知
• 业界统一参考标准：2 - 5 - 8

（7）TPS预估

• 系统的性能由TPS决定，跟并发用户数没有多大关系。系统最大的TPS是一定
  的，就好比池塘里装的水是有限的。但是并发用户数不一定，可以通过减小思
  考时间来增大并发用户数。

• 新系统：没有历史数据参考，只能通过业务部门来评估
• 旧系统：最好通过日志分析来得出

• 对于上线的系统，可以选取高峰时刻，在五分钟或者十分钟内，某个交易的最
  大值，按照单位时间内完成的笔数计算书TPS，即业务笔数/单位时间