性能测试基础笔记


一、性能测试

1、案例:

案例1.官方网站10月30日讯 今天上午9时,北京奥运会门票面向境内公众销售第二阶段准时启动。截至上午11时,各个销售渠道共售出门票约9000张,其中官方票务网站和中国银行各代售网点所售门票数量占98%。从今天上午的情况来看,公众购买门票的热情极其高涨。有些群众很早就来到中国银行排队等候;官方票务网站的浏览量在第一小时达到800万次,每秒钟从网上提交的门票申请超过20万张;票务呼叫中心热线从9点到10点的呼入量超过了200万人次。 ​ 案例2:2012年伦敦奥运会660万门票的网上预订在最后时刻重蹈了北京奥运会覆辙,网站订票系统抵挡不住巨大的需求而崩溃,最后不得不临时紧急延长了一个小时来解决这一尴尬问题。

2、什么系统需要做性能测试?

现有系统大致分为单机系统、C/S、B/S。这三类系统都应该进行性能测试,只是每个分类有各自特点,在实际测试中应该选择不同的策略进行对应。一般C/S架构的应用程序更关注于系统资源使用情况、数据库性能以及运行的配置要求等。例如,内存、用户连接数、数据库锁死、数据库cache命中率、运行的最低配置等。而B/S架构的应用程序,会关注Web服务器的相关指标,如每秒点击数、吞吐量、尝试连接数、事物成功率等。

3、性能测试的目的

  性能测试与功能测试有所不同,性能测试更加关注系统的性能表现。而性能测试就是排除系统瓶颈,使系统更加健壮。可以从以下几个方面理解:

  1)评估当前系统。系统未做过任何性能测试,对系统的当前性能情况不了解,缺少必要的的性能评估。

  2)寻找瓶颈,优化性能。常见的现象为,某业务操作响应时间很长、某系统上线一段时间后运行越来越慢,这些都需要分析定位并调优。

  3)预测未来性能。当用户数和业务量增加时能否及时应对?如何调整?是增加应用服务器,还是数据库服务器?还是要优化代码逻辑?这一系列问题都值得思考,这也是性能测试目的所在。

4、性能测试实施

1、原则:模拟人为的操作

2、方式:用工具(Jmeter等)模拟人,用线程来模拟人访问系统接口,使用工具的各种功能实现并达到测试目的

二、jmeter安装

1.先安装jdk2.下载jmeter放在 软件安装的盘符里面3.新建环境变量:JMETER_HOME  值:D:\tools\apache-jmeter-5.14. classpath %JMETER_HOME%\lib\ext\ApacheJMeter_core.jar;%JMETER_HOME%\lib\jorphan.jar;%JMETER_HOME%\lib/logkit-2.0.jar;

三、常用组件介绍

 

四、jmeter脚本开发的方式

1.手写,自己构建

常用

2.Jmeter的两种脚本录制方式

a.BadboyInstaller-2.2.5录制

b.jmeter代码录制脚本

五、关联

关联的内容就是session或者token,由于http协议是无状态的,为了解决这个问题就有session和token机制,后期请求都需要携带

a.从响应中提取sessionid:利用正则表达式提取器

2021-05-14_171116

jmeter中使用变量的值时需要保持格式 {变量名}

b.在cookie管理器中添加

六、jmeter参数化

1.方式一:(CSV数据文件)

使用csv 数据文件设置参数化

2021-05-17_110223

2.方式二:(函数助手)

使用函数助手进行参数化

2021-05-17_120526

2021-05-17_121129

注意:参数的数据文件不能写title,只能写数据,类似于下面这种

2021-05-17_121207

七、断言

1402725-20201030204435509-617790744

八、思考时间

思考时间指每一步骤直接的时间间隔,时间间隔是不一致的

注意:1s = 1000ms

固定定时器

image-20210517154937358

统一随机定时器

image-20210517155352533

九、集合点

 

十、Jmeter监听器

 

十一、Jmeter插件管理

 

十二、jmeter监控服务器:

1.需要安装插件

Servers Performance Monitoring

2.在被监控的服务器上安装jdk
1、上传文件解压[root@localhost tmp]# tar -zxvf jdk-8u172-linux-x64.tar.gz -C /opt[root@localhost tmp]# cd /opt[root@localhost opt]# mv jdk1.8.0_161 jdk1.82、配置环境变量[root@localhost /]# vim /etc/profile# 文件末尾追加 下面内容 shit+g 跳到文件末尾# JAVA_HOMEexport JAVA_HOME=/opt/jdk1.8export PATH=$PATH:$JAVA_HOME/bin#注意添加完成后需要执行命令配置生效[root@localhost /]# source /etc/profile3、检测安装成功[root@localhost /]# java -versionopenjdk version "1.8.0_161"OpenJDK Runtime Environment (build 1.8.0_161-b14)OpenJDK 64-Bit Server VM (build 25.161-b14, mixed mode)
3.将 ServerAgent-2.2.3.zip 放到任意目录下,解压
unzip  ServerAgent-2.2.3.zip

我提供的 ServerAgent 里面,两个 start 脚本已经是可执行脚本了,直接运行即可

./startAgent.sh

注意:ServerAgent默认使用的端口是4444,所有设置防火墙过滤规则

注意:Swap(交换空间)

Swap(交换空间):一般是指当虚拟机的虚拟内存不够用了,电脑系统会自动从磁盘开辟一段空间,分配给虚拟机当作内存使用(一般虚拟内存的大小为物理内存的2倍),由于磁盘的读写速度远远小于内存的读写速度,会导致虚拟机运行速度变慢。

 

十三、事物

1、什么是事物?

事物可以简单理解成完成某个业务的一系列操作,例如:在银行中,取款、存款这些都可以看成是一个事物

a.事物是可以组合的:例如:有人先存款、在取款,然后查询余额

b.在性能测试中,请求要输入某个的事物

c.性能测试中需要统计每秒钟事物数(TPS),在银行金融类项目中,需要统计事物的成功率

d.在jmeter中习惯一个线程组中放一个事物控制器,方便指定该事物的 虚拟用户数

 

十四、JMeter Concurrency Thread Group阶梯式加压

一、路径

项目-->线程(用户)-->(步进线程组)jp@gc - Stepping Thread Group (deprecated)

 

 

 

  • this group will start:表示总共要启动执行的线程数;若设置为 100,表示总共会加载到 100 个线程

  • first,wait for:从运行之后多长时间开始启动线程执行;若设置为 0 秒,表示运行之后立即启动线程执行

  • then start:初次启动多少个执行线程;若设置为 0 个,表示初次不启动执行线程

  • next add:之后每次启动加载多少个线程;若设置为 10个,表示每个梯次启动10 个线程

  • threads every:当前运行多长时间后再次启动加载线程,即每一次线程加载完成的持续运行时间;若设置为 30 秒,每梯次启动完执行完成后再运行 30 秒

  • using ramp-up:启动执行的的时间;若设置为 5 秒,表示每次启动执行线程都持续 5 秒(和基础执行绪组的ramp-up一样意思)

  • then hold load for:(持续负载)执行线程全部启动完之后持续运行多长时间,如图:设置为 60 秒,表示 100 个执行绪全部启动完之后再持续运行 60 秒

  • finally,stop/threads every:多长时间释放多少个线程;若设置为 5 个和 1 秒,表示持续负载结束之后每 1 秒钟释放 5 个线程

###

十五、Jmeter生成html报告

1、生成HTML测试报告的两种方式

1、利用已有.jtl文件生成报告

2、命令行界面直接运行脚本生成

 

十六、性能测试指标

一、系统性能指标(2点)

1、响应时间

i.定义及解释

从客户端发送请求然后服务端给出响应所用时间

响应时间越短越好,这里面的响应时间指的平均响应时间

ii.简称

Response Time:RT

iii.参考标准

不同行业的不同业务可接受的响应时间是不同的,一般情况下,对于在线实时交易:

  • 互联网企业:500毫秒以下,例如淘宝业务10毫秒左右。

  • 金融企业:1秒以下为佳,部分复杂业务3秒以下。

  • 保险企业:3秒以下为佳。

  • 制造业:5秒以下为佳。

2、吞吐量(系统处理能力)

i.定义及解释

通过系统每秒钟能够处理的交易数量来评价

交易的两种解释:

(业务人员角度)---业务交易过程

(系统角度)---事物

ii.简称

一般情况下,用以下几个指标来度量:

  • HPS(Hits Per Second) :每秒点击次数,单位是次/秒。

  • TPS(Transaction per Second):系统每秒处理交易数,单位是笔/秒。

  • QPS(Query per Second):系统每秒处理查询次数,单位是次/秒。 对于互联网业务中,如果某些业务有且仅有一个请求连接,那么TPS=QPS=HPS,一般情况下用TPS来衡量整个业务流程,用QPS来衡量接口查询次数,用HPS来表示对服务器单击请求。

  • 并发用户数

  • 错误率

iii. 标准(TPS、QPS、HPS越大越好)衡量系统处理能力的重要指标

无论TPS、QPS、HPS,此指标是衡量系统处理能力非常重要的指标,越大越好,根据经验,一般情况下:

  • 金融行业:1000TPS~50000TPS,不包括互联网化的活动

  • 保险行业:100TPS~100000TPS,不包括互联网化的活动

  • 制造行业:10TPS~5000TPS

  • 互联网电子商务:10000TPS~1000000TPS

  • 互联网中型网站:1000TPS~50000TPS

  • 互联网小型网站:500TPS~10000TPS

 

、资源指标(4点)

1.CPU

i.定义及解释

ii.简称

Central Processing Unit: CPU

iii.标准

CPU指标

  • CPU指标主要指的CPU使用率利用率,包括用户态(user)、系统态(sys)、等待态(wait)、空闲态(idle)。

  • CPU利用率要小于等于业界警戒值(75%)

  • CPU sys%小于或者等于30%,

  • CPU wait%小于或者等于5%。

  • 单核CPU也需遵循上述指标要求。

  • CPU load(负载)要小于CPU核数。

2.内存(Memory

i.定义及解释

ii.简称

Disk Throughput

iii.标准

现代的操作系统为了最大利用内存,在内存中存放了缓存,因此内存利用率100%并不代表内存有瓶颈,衡量系统内有有瓶颈主要靠SWAP(与虚拟内存交换)交换空间利用率,一般情况下,SWAP交换空间利用率要低于70%,太多的交换将会引起系统性能低下。

3.磁盘

i.定义及解释

无磁盘故障的情况下单位时间内通过磁盘的数据量。

ii.简称

Disk Throughput。

iii.标准

磁盘指标主要有每秒读写多少兆,磁盘繁忙率,磁盘队列数,平均服务时间,平均等待时间,空间利用率。其中磁盘繁忙率是直接反映磁盘是否有瓶颈的重要依据,一般情况下,磁盘繁忙率要低于70%。

4.网络

i.定义及解释

无网络故障的情况下单位时间内通过的网络的数据数量

ii.简称

Network Throughput

iii.标准

网络吞吐量指标主要有每秒有多少兆流量进出,一般情况下不能超过设备或链路最大传输能力的70%。

三、中间件指标

1.定义及解释

常用的中间件例如Tomcat、Weblogic等指标主要包括JVM, ThreadPool, JDBC

 

十七、性能测试分类

1、基准测试

1.先使用一个线程执行脚本

2.更换不同的硬件配置,来调整服务器硬件资源,看运行情况,进行优化

2、压力测试

压力测试是指在一定的软件、硬件及网络环境下,模拟大量的虚拟用户数向服务器产生负载,使服务器的资源处于极限状态下并长时间连续运行,以测试服务器在高负载情况下是否能够稳定工作。

3、负载测试

负载测试是值在一定的软件、硬件及网络环境下,运行一种或多种业务,在不同虚拟用户数量的情况下,测试服务器的性能指标是否在用户的要求范围(75%)内,以此确定系统所能承受的最大用户数、最大有效用户数以及不同用户数下的系统响应时间及服务器的资源利用率。

4、并发测试

1.狭义角度:所有的人,同一时间做相同的操作,例如,同时进行登录,在自然界绝对的并发并不存在

2.广义的并发:只要对于我们当前项目系统产生压力,就可以看作是一个并发

报告给老板的是负载测试的结果,即在一定标准范围内

 

并发数如何确定?

  并发数 = PV/PVTime 页面连接次数 HTTP响应时间 * 因数/Web服务器数量。

  其中,PVTime是PV的统计时间,换算成秒,一天是86400s。页面连接次数包括外部的JS、CSS、图片等,一般为10。HTTP响应时间一般为1s或更少。因数一般为5。

  假设,BestTest官网每天有6万PV,其余参数保持默认,那么推算出来的并发数大致为35

  注意**:PV(page view)即页面浏览量。一个用户有可能创造十几个甚至更多的PV。它是目前判断网站访问流量最常见的计算方式,也是反映一个网站受欢迎程度的重要指标。

十八、jmeter分布式压测

一、jmeter为什么要做分布式压测

二、分布式原理

三、分布式压测的前提条件已经配置

注意:(contorller控制机,slave压力机)

1、控制机和压力机的JDK和jmeter,插件等版本必须一致

2、做参数化的测试数据读取路径要一致

3、在同一个子网络中

4、

十九、性能测试场景分析

一、应用性能测试场景的设计

1.业务场景建模

 

2.测试数据准备

3.确认监控指标

二、应用性能测试场景设计的实践

 

 

 

 

 

 

 

 

 

posted on 2021-05-31 15:00  lisa^sHusband  阅读(180)  评论(0编辑  收藏  举报