Loadrunner压测结果性能问题分析指标项

事务分析内容:
用户事务分析是站在用户角度进行的基础性能分析。
1、Transation Sunmmary(事务综述)
对事务进行综合分析在一定测试时间内用户事务的成功与失败情况,判断系统是否正常运行。

2、Average Transaciton Response Time(事务平均响应时间)
测试场景运行期间的事务执行所用的平均时间,通过它可以分析测试场景运行期间应用系统的性能走向。

3、Transactions per Second(每秒通过事务数)
在场景运行的每1秒每个事务通过、失败以及停止的数量,分析TPS主要是看曲线的性能走向。
例:当压力加大时,点击率/TPS曲线如果变化缓慢或者有平坦的趋势,很有可能是服务器开始出现瓶颈。

4、Total Transactions per Second(每秒通过事务总数)
显示在场景运行时,在每一秒内通过的事务总数、失败的事务总署以及停止的事务总数。

5、Transaction Performance Sunmmary(事务性能摘要)
事务性能摘要:显示所有事务的最小、最大和平均执行时间,可以直接判断响应时间是否符合用户的要求。

6、Transaction Response Time Under Load(事务响应时间与负载)
“事务响应时间与负载”是“正在运行的虚拟用户”图和“平均响应事务时间”图的组合,通过它可以看出在任一时间点事务响应时间与用户数目的关系,从而掌握系统在用户并发方面的性能数据,为扩展用户系统提供参考。

Web资源分析内容:
1、Hits per Second(每秒点击次数)
“每秒点击次数”,即使运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。

2、Throughput(吞吐率)
“吞吐率”显示的是场景运行过程中服务器的每秒的吞吐量。其度量单位是字节,表示虚拟用在任何给定的每一秒
从服务器获得的数据量。
可以依据服务器的吞吐量来评估虚拟用户产生的负载量,以及看出服务器在流量方面的处理能力以及是否存在瓶颈。

3、HTTP Status Code Summary(HTTP状态代码概要)
“HTTP状态代码概要”显示场景或会话步骤过程中从Web服务器返回的HTTP状态代码数,
该图按照代码分组。 HTTP状态代码表示HTTP请求的状态,类似如下:
2xx - 成功
3xx - 重定向
4xx - 客户端错误
500 - 内部服务器错误。*

4、HTTP Responses per Second(每秒HTTP响应数)
每秒HTTP响应数:是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量,
还能返回其它各类状态码的信息,通过分析状态码,可以判断服务器在压力下的运行情况。

5、Pages Downloader per Second(每秒下载页面数)
每秒下载页面数:每一秒内从服务器下载的网页数。使用此图可依据下载的页数来计算Vuser生成的负载量。

6、Retries per Second(每秒重试次数)
“每秒重试次数”显示场景或会话步骤运行的每一秒内服务器尝试的连接次数。
在下列情况将重试服务器连接:
A、初始连接未经授权
B、要求代理服务器身份验证
C、服务器关闭了初始连接
D、初始连接无法连接到服务器
E、服务器最初无法解析负载生成器的IP地址

7、Connections(连接数)
连接数:显示场景或会话步骤运行过程中每个时间点打开的TCP/IP连接数。借助此图,
可以知道何时需要添加其他连接。

8、Connections Per Second(每秒连接数)
每秒连接数:显示在运行过程中每秒建立的TCP/IP连接数。

9、SSLs Per Second(每秒SSL连接数)
每秒SSL连接数:显示场景或会话步骤运行的每一秒内打开的新的以及重新使用的SSL连接数。
当对安全服务器打开TCP/IP连接后,浏览器将打开SSL连接。

网页元素细分项:
1、Download Time Breaddown(下载时间细分)
下载时间细分:图显示网页中不同元素的下载时间,同时还可按照下载过程把时间进行分解,
用不同的颜色来显示DNS解析时间、建立连接时间、第一次缓冲时间等各自所占比例。

2、Component Breakdown(Over Time)(组件细分(随时间变化))
组件细分:显示选定网页的页面组件随时间变化的细分图。通过该图可以很容易的看出哪些
元素在测试过程中下载时间不稳定。

3、Download Time Breakdown(Over Time)(下载时间细分(随时间变化))
下载时间细分: 图显示选定网页的页面元素下载时间细分情况,它非常清晰地显示了页面各个
元素在压力测试过程中的下载情况。

4、Time to First Buffer Breakdown(Over Time)(第一次缓冲时间细分(随时间变化))
第一次缓冲时间细分:显示成功收到Web服务器返回的第一次缓冲之前的这段时间,
场景或会话步骤运行的每一秒中每个网页组件的服务器时间和网络时间(以秒为单位)。
可以使用该图确定场景或会话步骤运行期间服务器或网络出现问题的时间。
First Buffer Time:是指客户端与服务器端建立连接后,从服务器发送第一个数据包开始计时,
数据经过网络传送到客户端,到浏览器接收到第一个缓冲所用的时间。

5、Page Component Breakdown(页面组件细分)
页面组件细分:图显示每个网页及其组件的平均下载时间(以秒为单位)。

6、Page Component Breakdown(Over Time)(页面组件分解(随时间变化))
页面组件分解(随时间变化):图显示压测运行期间的每一秒内每个网页及其组件的平均响应时间 (以秒为单位)。

7、Page Download Time Breakdown(页面下载时间细分)
页面下载时间细分:图显示每个页面组件下载时间的细分,可以根据它确定在网页下载期间事务响应
时间缓慢是由网络错误引起还是由服务器错误引起。

8、Page Download Time Breakdown(Over Time)(页面下载时间细分(随时间变化))
页面下载时间细分:显示压测运行期间,每一秒内每个页面组件下载时间的细分。

9、Time to First Buffer Breakdown(第一次缓冲时间细分)
第一次缓冲时间细分:显示成功收到从Web服务器返回的第一次缓冲之前的这一段时间内的每个
页面组件的相关服务器/网路时间。如果组件的下载时间很长,则可以使用此图确定产生的问题与
服务器有关还是与网络有关。
网络时间:定义为第一个HTTP请求那一刻开始,直到确认为止所经过的平均时间。
服务器时间:定义为从收到初始HTTP请求确认开始,直到成功收到来自Web服务器的一次缓冲为止所经过的
平均时间。
10、Downloader Component Size(KB)(已下载组件大小)
已下载组件大小:显示每个已经下载的网页组建的大小。

原文地址:https://blog.51cto.com/372550/2431123

时间: 2024-10-02 01:03:52

Loadrunner压测结果性能问题分析指标项的相关文章

web压测工具http_load原理分析

原文:web压测工具http_load原理分析 一.前言 http_load是一款测试web服务器性能的开源工具,从下面的网址可以下载到最新版本的http_load: http://www.acme.com/software/http_load/ (页面实在太简陋……) 十分令人欣慰的是,这个软件一直在保持着更新(不像webbench,已经是十年的老古董了.webbench的源码分析请参考:http://www.cnblogs.com/xuning/p/3888699.html ),并且更新频率

记5.28大促压测的性能优化—线程池相关问题

目录: 1.环境介绍 2.症状 3.诊断 4.结论 5.解决 6.对比java实现 废话就不多说了,本文分享下博主在5.28大促压测期间解决的一个性能问题,觉得这个还是比较有意思的,值得总结拿出来分享下. 博主所服务的部门是作为公共业务平台,公共业务平台支持上层所有业务系统(2C.UGC.直播等).平台中核心之一的就是订单域相关服务,下单服务.查单服务.支付回调服务,当然结算页暂时还是我们负责,结算页负责承上启下进行下单.结算.跳支付中心.每次业务方进行大促期间平台都要进行一次常规压测,做到心里

记5.28大促压测的性能优化—线程池相关问题

目录: 1.环境介绍 2.症状 3.诊断 4.结论 5.解决 6.对比java实现 废话就不多说了,本文分享下博主在5.28大促压测期间解决的一个性能问题,觉得这个还是比较有意思的,值得总结拿出来分享下. 博主所服务的部门是作为公共业务平台,公共业务平台支持上层所有业务系统(2C.UGC.直播等).平台中核心之一的就是订单域相关服务,下单服务.查单服务.支付回调服务,当然结算页暂时还是我们负责,结算页负责承上启下进行下单.结算.跳支付中心.每次业务方进行大促期间平台都要进行一次常规压测,做到心里

loadrunner压测 1--工具

压测工具:loadrunner 监控工具:f5.Zabbix.secureCRT 工具说明: F5负载均衡  是一个硬件设备,可以通过浏览器监控压测时候的总人数.并发.相同的服务.多个IP地址,可以在F5上做一个对外虚ip,压测的时候直接填对外虚ip,怎么交给后端服务器 就是f5来处理了.生产上这种情况很多,一个机器对应一个服务,每个服务都是多个ip地址. 举个例子: 1.1和1.2是wechat-front1和wechat-front2这两个服务自己的IP,测试的时候不可能把1.1和1.2都绑

loadrunner压测实施工艺步骤

对于有若干个复杂的联机交易业务流管理系统的公司,公司内部测试团队对于性能测试实施管理方式都有一套轻量型的工作模式让新手借鉴学习,以便在实施压测类似系统过程中能快速上手,降低误差率和不必要的沟通管理成本,如下流程是我们在压测中编写的一套基本的LR工作实施工艺来让新手能快速熟悉,如下: 一.录制维护脚本 录制脚本前先手动熟悉功能. 录制脚本,如果功能比较简单,则放置action中:如果功能比较复杂,则需要多个action,如流程,每个步骤一个action.其中每个动作都需要设置一个事务. 为了确保自

Jmeter压测与性能监控自动化(二)

基于Jmeter的接口性能测试自动化框架,JMeter+ant+Jenkins主要包括6个部分: 1. 脚本和数据分离实现 jmeter脚本中的服务地址和参数均进行参数化配置,通过配置文件读取,例如dubbo地址变化,直接修改csv配置文件即可 后续考虑将这块做成web页面的,通过web页面上传脚本和配置文件,可设置并发数,压测曲线是梯度还是平行等 2. 批量执行脚本 利用ant批量跑指定目录下的Jmeter脚本,如有新增脚本只要放置在指定目录即可 3. 生成接口运行报告 4. 定位报错接口 5

LoadRunner 压测场景制定

这里,我们利用 LoadRunner 来制定场景 前提:准备好没问题的脚本以及数据 进入压测场景的方式有两种,这里,我们示范两种方式的进入手工设定场景1.直接进入 Run Load Tests 2.从脚本显示页进入 原文地址:https://www.cnblogs.com/xiaowenshu/p/10354868.html

百度压测,分析性能拐点

概述 空闲之余用jmeter对百度进行了一次压测,目的是分析一下性能的拐点,验证一下理论知识 操作 第一次实验:200并发 并发200,不限迭代次数,同时在请求下面加RPS定时器. 目的是在200线程下,将RPS逐步增加到1200/S,并持续运行一段时间. 在线程下面添加TPS,HPS,响应时间三种监听器 启动jmeter,运行一段时间之后我们观察一下监听器的数据图表. RPS 在793/s的时候,出现拐点,请求曲线的角度开始收窄 TPS在 720/s左右开始出现剧烈波动,前期一直保持平稳上升,

后端服务性能压测实践

转自:https://mp.weixin.qq.com/s/XW9geHZ9odHdI7srDiKBIg 目录 背景 环境检测 压力机及压力工具检测 Linux openfiles limit 设置 排查周边依赖 空接口压测检测 聚合报告中 throughput 计算 压测及性能排查方法 关注各纬度 log Linux 常规命令 性能排查两种方式(从上往下.从下往上) 总结 背景 最近大半年内有过两次负责性能压测的一些工作.一件事情做了一次可能还无法总结出一些东西,两次过后还是能发现一些共性问题