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,即业务笔数/单位时间

转载于:https://www.cnblogs.com/wwho/p/8514099.html

你可能感兴趣的:(Loadrunner-场景设置以及监控结果分析)