性能测试需求分析 业务PV量,响应时间、QPS、TPS

一、 性能测试需求分析

1.1      性能测试需求内容

性能测试需求应包括以下内容:

a)    测试场景及用例,用例访问URL;

b)   目标接口方法的入参、出参;

c)    外部依赖的服务细节;

d)  关键数据: 数据量、高峰业务PV量

e)  预期性能指标:响应时间、QPS、TPS等

性能测试需求模板表格参考如下:

性能测试(1) ---性能测试需求收集

1.2 预期性能指标1.2.1数据量
测试环境的数据量,应该跟线上环境保持一致,至少要在一个数量级。

举例有,中文站线上的每秒登录用户数据量平时为20个,特殊情况下,每秒为10万,那么测试环境要保证正常情况下在20个左右,至少是十的数量级,性能测试特殊情况下,要准备十万级的数据量,模拟最高并发用户数据量。

1.2.2高峰业务PV量
     1) 二八法

若80%的访问量集中在20%的时间里,可用此分析方法,其图形就是一个正态分布图,如下。

具体计算公式为:

tps = (24小时的PV值*80%)/(24*3600*20%)

举例有,假如中文站每日的访问量为500万,其中19:00-23:40,访问量为400万,其余时间段的访问量很平坦,而且其余时间段的总访问量为100万,那么就可以用二八法,其计算公式为 tps = (500万*0.8)/(24*3600*0.2)。

2)简单峰值法

若在每天的某一时段里有很大的访问量,其他时间相对较少,可以用简单峰值法,其实二八法只是简单峰值法的一个特例。

具体计算公式为:

tps =(24小时的PV值)/(峰值时间段中的小时数*3600)

举例有,假如中文站每日的访问量为500万,其中17:00-24:00这个时间段里面访问量为450万,其他时间段的访问量很平缓,那么,我可以用简单峰值法近似计算,其计算公式为 tps = 500万/((24-17)*3600)

3)无峰值法

若24小时里的访问量都是平稳波动的,没有峰值,那么可以采用无峰值计算方法,图形如下。

具体计算公式为:

tps= (24小时的PV值)/(24*3600)

举例有,假如中文站每日的访问量为500万,每小时的访问量都为20万左右,那么,可以用无峰值法来近似计算,其计算公式为 tps = 500万/(24*3600)。

1.2.3吞吐量
      指软件系统在每单位时间内能处理多少事务/请求/单位数据等,

其与tps的近似计算公式为:(单位为秒)

tps = 这段时间内的总样本数/(最后一个请求完成的时刻-第一个请求发起的时刻)

可以这样举例,假如,在17:58的0 秒发起第一个请求,在18:02分0秒完成最后一个请求,在这4分钟整的期间,共处理的总的样本数为1000个,那么,可以这样近似计算:

tps = 1000/(4*60)

值得注意的是,因为每个请求之间的空闲值也包含在内了,故tps是有误差的,而且tps是个平均值。

来源: <http://blog.sina.com.cn/s/blog_639aa08501010kkr.html>

需求收集之后,我们已经从性能需求文档中提取出了业务性能测试指标,主要包括PV到TPS的转换以及响应时间要求,接下来我们需要进行进一步的需求分析过程。

1了解系统架构、明确压力流向
    例如统一订购平台的系统架构图:

理解架构图中各个节点的功能与交互关系,通过系统架构图我们能看到压力的入口,即oop应用。请求从oop发起,从udb取到会员数据后,通过dubbo接口,调用订购服务层提供的各种服务,订购服务层所需数据全部从对应cache中取。因此,主干压力流向可得知:

Oop—>udb

Oop—>dubbo—>订购服务层—>cache

然后结合需求文档,根据具体业务场景,确定各分支压力流向,比如有的业务场景需要从pc2取得用户的服务记录,有的业务场景需要付款则需要去帐户中心取得帐户信息,则新增的压力流向如下:

Oop—>dubbo—>pc2—>cache

Oop—>dubbo—>帐户中心

针对每一个测试场景,都要根据系统架构图进行上述分析,明确了各场景的压力流向,即明确了性能测试过程中的监控对象。

监控对象确定后,需要进一步分析明确测试重点,如上例,我们关注的重点是网站的oop应用,因为平台的udb、pc2,crm的服务订购中心,都有各自做过接口性能测试。或者有的所用应用功能是线上已有的,并没有修改变动,如帐户中心。明确测试重点,将有助于我们进行测试环境相关的测试策略的选择。

2 明确测试环境2.1 服务器数量确定
根据系统架构图,我们得到了项目中所涉及的环境。众所周知,测试环境越接近生产环境,则测试结果越精确。但通常我们会碰到服务器资源紧张,或者所用应用为外部门的外围环境,搭建方法复杂。此时我们面临两种选择,要么使用功能环境,要么mock掉该环境。建议不要选择前者,可以多个压力流向小的应用公用一台性能服务器。

2.2 服务器配置确定
还是一条不变的原则:测试环境软硬件配置尽量与生产环境保持一致。

机器的性能需求:32位or64位;4核or8核;是否要求同一网段

测试环境软件架构确定(jdk、apache、jboss版本、jvm参数):与线上环境一致,重点关注jvm参数配置,确保与线上一致。

性能测试关注的主要硬件配置及OS参数如下表:

主机/ip

硬件配置

操作系统及参数调整

10.20.133.165

统一订购层应用服务器

机型

PowerEdge 1950

Linux  2.6.18-92.el5

64位操作系统

CPU

Intel(R) Xeon(R) CPU E5410  @ 2.33GHz * 8

内存

10G

网络

1000M

应用服务器配置检查中常用的linux指令:

查看机型: dmidecode --type 1|grep "Product Name"

查看CPU: cat /proc/cpuinfo

查看内存:free -mt

红框内即为本机内存总量

查看网卡:

1)ifconfig 检查服务器连接的哪块网卡(ethx)

上图红框内即为当前活动的网卡

2)ethtool ethx 检查网卡详细信息(ethx为ifconfig检查出来的网卡编号,如上图就为eth0)

上图红框内即为当前网卡带宽(双工模式)

查看操作系统:

uanme -a 查看所有信息

uname -o, --operating-system    GNU/Linux

-r, --kernel-release      2.6.18-128.el5(操作系统内核版本)

-i, --hardware-platform   x86_64(硬件版本)

-o, --operating-system    x86_64(操作系统版本)

3      关键业务数据量分析3.1 数据量需求确认
1) 数据量是指的性能测试需要考虑的数据总量和数据类型。

例如在offer数据量为30w的DB中查询和在offer数据量为1000w的DB中查询,性能表现一定是不一样的。我们需要考虑,现阶段的数据量等级和未来发展趋势下的数据量等级。有的时候数据量也是程序分支逻辑,所以这点就必须详细考虑了。

2)    存储分布指的数据源的分布情况,是分布式分布还是单台分布;是search分布还是DB分布,等等。例如offer拆分项目的性能测试就需要综合考虑Oracle单表、Oracle16张表、mysql128张表的使用场景

3)    基本要求:测试数据库数据量要与线上数据量保持一个数量级。

3.2 造数据方法确定
根据数量级的需要,可以采用不同的方法,大致有以下几种:

1) 找DBA帮忙导线上/测试库数据;

2) 用datafactory/sql直接插数据库;(查看datafactory文档)

界面如图,具体使用方法问google

3) 用jmeter/LR/ruby等脚本走正常业务流造数据。(查看各脚本录制方法)

3.3划分测试场景、明确测试用例
测试用例的产生需要考虑以下几方面:

1)    测试页面和业务逻辑,也就是业务对应的功能点

注意,性能测试的测试用例也需要专一性,也就是对应单个测试功能点。

因为我们监控的是每个事物的响应时间,功能点需要单一。

2)    压力持续时间

压力持续时间指的是给服务器施加多长时间的压力。

这个时间,我们会结合测试场景,对压力时间做一定的控制。

ü  如果测试的是高峰场景,时间一般最少为1个小时;

ü  如果测试的是稳定性场景,时间一般最少要求8小时;

3)    并发数

不要混淆并发和TPS的关系。

并发数指的是同时有多少用户(线程)在对服务器施加压力,是量化的给服务器的压力;而TPS指的是服务器每秒钟能够处理的事物数,是服务器处理能力的体现。

来源: <http://blog.sina.com.cn/s/blog_639aa08501010kkx.html>

时间: 2024-10-11 16:24:54

性能测试需求分析 业务PV量,响应时间、QPS、TPS的相关文章

【原创】性能测试之——性能测试需求分析

性能测试之——性能测试需求分析 这里以一个电商购物(B2C)网站为例: 客户的购物网站性能测试(业务)需求: 从12月下旬至农历年底(来年2月初)(<=50天)网站预计营业额(400万),这里营业额可以理解为网站完成购买订单总金额: 访问订单转化率:10%,这里理解为百分之多少的访问量会转化为实际的网站订单: 每日访问时间:24小时×80%,这里理解为正常用户会在早6点至凌晨0点之前进行电子购物,下午18点下班至晚上22点为购物高峰期: 每个订单平均选购商品数:3件左右共计300元左右的金额,这

关于并发用户数的思考-通过PV量换算并发

首先介绍一下pv量:PV(访问量):即Page View, 即页面浏览量或点击量,用户每次刷新即被计算一次.UV(独立访客):即Unique Visitor,访问您网站的一台电脑客户端为一个访客.00:00-24:00内相同的客户端只被计算一次.IP(独立IP):即Internet Protocol,指独立IP数.00:00-24:00内相同IP地址之被计算一次.***************************问题:一个系统的日均pv量是8000,那么并发用户数应该是多少? 1.首先,我觉

根据PV量来确定需要进行压测的并发量

在实际做压力测试的过程中,我们有时不知道用怎样的并发量比较好,下面是几个用PV量去确定并发量的公式,这个在我们公司是比较适用的,大家可以根据自己的业务进行运算. 方法一:这个方法是我在网上查到的80-20原则,具体运算方法为: X*0.8/(8*60*60*0.2) 说明:X为要压测页面的PV量 方法二:这个是将PV量除以高峰时段小时(比如9:00-17:00,就是8个小时),再除以60*60细化到秒,然后乘以12倍,已获得想要的并发量 (X/8/60/60)*12 说明:X为要压测页面的PV量

mysql状态查看 QPS/TPS/缓存命中率查看

mysql状态查看 QPS/TPS/缓存命中率查看 运行中的mysql状态查看 对正在运行的mysql进行监控,其中一个方式就是查看mysql运行状态. (1)QPS(每秒Query量) QPS = Questions(or Queries) / seconds mysql > show  global  status like 'Question%'; (2)TPS(每秒事务量) TPS = (Com_commit + Com_rollback) / seconds mysql > show

测算Redis处理实际生产请求的QPS/TPS

测算Redis处理实际生产请求的QPS/TPS Benchmark工具 redis发布版本中自带了redis-benchmark性能测试工具; 示例: 使用50个并发连接,发出100000个请求,每个请求的数据为2kb, 测试host为127.0.0.1 端口为6379的redis服务器性能: ./redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -d 2 ... ====== SADD ====== 100000 requests com

Mysql 监控性能状态 QPS/TPS【转】

QPS(Query per second) 每秒查询量 TPS(Transaction per second)每秒事务量 这是Mysql的两个重要性能指标,需要经常查看,和Mysql基准测试的结果对比,如果值过高,就要尽快处理了 计算方法 01 QPS QPS = Queries / Seconds Queries 是系统状态值--总查询次数,可以通过 show status 查询得出 Seconds 是监控的时间区间,单位为秒 例如采样10秒内的查询次数,那么先查询一次Queries值(Q1)

Loadrunner根据PV量来确定需要进行压测的并发量

在实际做压力测试的过程中,我们有时不知道用怎样的并发量比较好,下面是几个用PV量去确定并发量的公式,这个在我们公司是比较适用的,大家可以根据自己的业务进行运算. 方法一:这个方法是我在网上查到的80-20原则,具体运算方法为: X*0.8/(8*60*60*0.2) 说明:X为要压测页面的PV量 方法二:这个是将PV量除以高峰时段小时(比如9:00-17:00,就是8个小时),再除以60*60细化到秒,然后乘以12倍,已获得想要的并发量 (X/8/60/60)*12 说明:X为要压测页面的PV量

QPS/TPS简介

系统吞度量要素 一个系统的吞度量(承压能力)与request对CPU的消耗.外部接口.IO等等紧密关联.单个reqeust 对CPU消耗越高,外部系统接口.IO影响速度越慢,系统吞吐能力越低,反之越高.系统吞吐量几个重要参数:QPS(TPS).并发数.响应时间QPS(TPS):每秒钟request/事务 数量并发数: 系统同时处理的request/事务数响应时间: 一般取平均响应时间QPS(TPS)= 并发数/平均响应时间 一个系统吞吐量通常由QPS(TPS).并发数两个因素决定,每套系统这两个

mysql QPS TPS

QPS:Queries Per Second         查询量/秒,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理查询量多少的衡量标准. TPS :  Transactions Per Second   是事务数/秒,是一台数据库服务器在单位时间内处理的事务的个数. 很多资料上对QPS TPS的算法都是 questions = show global status like 'queries'; uptime = show global status lik