基于协议的性能测试7大类:压力测试,负载测试,配置测试,基准测试,并发测试,容量测试。
在一定的软硬件,网络条件下,模拟用户高并发(峰值负载),持续一段时间,检测系统的各项性能指标,关注峰值下的系统的性能表现。
目的:监测被测系统在峰值的运行情况(系统崩溃),给最坏情况的设计预案。
场景模型:门型场景
在一定的软硬件,网络条件下,通过改变负载的方式,监测系统各项性能指标,得到系统在正常工作的情况下,系统的最大用户数,最佳用户数,定位系统的瓶颈。(施压但不会压死)
场景模型:拱形场景
改变软硬件配置(架构配置,参数配置),观测不同的配置条件下的性能状态(比如:CPU,内存,服务器)
目的:找到最优的配置。
在一定的软硬件,网络条件下,模拟单用户操作系统,监测系统各项性能指标。(一个用户的时候响应时间是否达标,再测多个用户)
目的:为后面深入的性能测试做一个数据对比。
测试同一模块,同一应用在高并发的情况下,接口工作是否正常。
目的:主要是检查应用或者是接口在多用户情况下,是否存在缺陷(比如死锁)
在一定的硬件,网络条件下,改变数据库的容量,模拟多用户,监测各项性能指标的过程
目的:寻找数据库的容量的极限值。
主要强调长时间,正常负载情况下,观测系统各项指标的稳定性,不会出现致命的问题。
目的:检验系统长时间运行,系统的稳定性,是否有异常情况。
上新系统
用户场景(大量用户,同时使用,某个时间段使用),基准测试,负载测试,压力测试,容量测试。
系统扩容
分析了解历史系统自身的性能表现,适当的扩容。基准测试,负载测试,压力测试,容量测试。
系统优化
针对已上线的系统越来越慢,对系统进行优化配置,提升性能表现。基准测试,配置测试。
系统修复
解决线上系统的并发死锁,内存泄漏等问题。并发测试
秒杀/团购
基准测试,负载测试,压力测试
在功能测试,接口测试都已经完成之后再做性能测试。
业务指标:并发用户数,在线用户数,平均响应时间,事务成功率,超时错误率。
系统资源指标:数据库服务器,应用服务器,web服务器的CPU、内存、硬盘、外置存储、网络带宽的使用率。低于20%的使用率为资源空闲,20%~60%的使用率为资源使用稳定,60%-80%的使用率表示资源使用饱和,超过80%的资源使用率必须尽快进行资源调整和优化。
Response Time 单位毫秒,秒,由网络时间,服务器处理时间,网络延迟三大部分组成。
响应时间构成= C1 + N1 + A1+ N2 + N3 + A2 + A3 + N4 + C2
Through output衡量系统的业务能力。
吞吐量为“单位时间内系统处理的客户请求的数量”。在容量规划的测试中,吞吐量是一个重量指标。
业务角度来看,单位可用请求数/秒,页面数/秒,人数/天或处理业务数/小时;
网络角度来看,单位可用字节/秒来衡量。
对于交互式应用来说,吞吐量反映的是服务器承受的压力,它能够说明系统的负载能力。
事务是分粒度的,可大可小,搜索商品就是一个小的事物,由一个请求组成,而购物这个事务则由浏览商品,加入购物车,付款等多个不同请求组成的。
TPS(Transaction per second):每秒事务数。TPS反映了系统在同一时间内能够处理业务的最大能力。
QPS(Query per second):每秒请求数
点击率与TPS最大的区别是:TPS体现的是服务器对客户端请求的处理能力;而点击率体现的是客户端对服务器的压力。
CPU,内存,网络,磁盘读写IO
CPU占用率(CPU Utilization)
如果该值持续超过95%,则表明瓶颈是CPU,可以考虑增加一个处理器或更换一个更快的处理器。一般可接受的最大上限是80%-85%,合理使用的范围在60%-70%以下。
System/Processor Queue Length
如果System/Processor Queue Length>2,而处理器利用率(Processor Time)一直很低,则存在着处理器阻塞。
CPU资源成为系统性能瓶颈的征兆
很慢的响应时间(slow response time);
CPU空闲时间为零(zero percent idle CPU);
过高的用户占用CPU时间(high percent user CPU);
过高的系统占用CPU时间(high percent system CPU);
长时间的有很长的运行进程队列(large run queue size sustained over time)
磁盘交换率(Disk Rate)
如果该参数值一直很高,则表明I/O有问题。可考虑更换更快的硬盘系统。
Disk Time 和 Avg.Disk Queue Length
当这两个值很高,而Page Reads/sec(页面读取操作速率)很低时,则可能存在磁盘瓶颈。
I/O资源成为系统性能瓶颈的征兆
过高的磁盘利用率(high disk utilization);
太长的磁盘等待队列(large disk queue length);
等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O);
太长的运行进程队列,但CPU却空闲(large run queue with idle CPU);
太高的物理I/O速率【large physical I/O rate (not sufficient in itself)】;
过低的缓存命中率【low buffer cache hit ratio (not sufficient in itself)】;
一般使用计数器Bytes Total/sec来度量,表示为发送和接收字节的速率,包括帧字符在内。减小网络带宽,并发一壶水,响应时间与事务通过率等性能指标是否不能接受,反之。
拐点分析法:找出资源利用率的最佳状态。
系统在负载情况下,失败请求的概率
错误率=(失败请求数/请求总数)* 100%
和功能测试的错误区别:在性能测试中,所谓的错误一般是指由系统超时引起的错误,不同的系统对错误率的容忍限度不同。
客户端每发送一个请求,服务器就处理一次,所以点击数是web应用处理交易的最小单位。点击率越大,对服务器的压力相对也越大。
性能测试常见的专业术语:集合点,关联,检查点(断言),用户数,PV(页面访问量),UV(独立用户访问量)。
(1)需求获取
客户提出要求
提到系统有多少,同时在线使用人数是多少,使用系统高峰时间等需求。
开发相关文档
历史数据(日志)
运行中的日志:主要记录运行的一些信息,特别是一些异常错误日志信息;
访问日志信息:它记录访问的时间,IP,访问的资料等相关信息。
根据时间段做以下分析处理:
独立IP数统计;
访问请求数统计;
访问资料文件数统计;
访问流量统计;
访问处理响应时间统计;
统计所有404错误的页面;
统计所有500错误的页面;
统计访问最频繁的页面;
统计访问处理时间最久的页面;
统计并发访问频率最高的页面;
相似项目性能需求
业界公认标准
响应时间2-5-8原则
评估指标 | 采集频率 | 指标说明 |
---|---|---|
CPU资源 | 5秒 | 反映主机CPU健康状态 |
内存资源 | 5秒 | 反映主机内存健康状态 |
I/O资源 | 5秒 | 反映主机I/O健康状态 |
(1)CPU监控命令:vmstat 5 10(每隔5秒输出一次结果,共输出10次结果)
r:运行队列(就是说多少个进程真正分配到CPU)。如果运行队列过大,则表示CPU繁忙,一般会造成CPU使用率很高。
b:等待队列中的内核线程平均数。
swpd:虚拟内存已使用的大小,如果大于0,则表示机器的物理内存不足。如果不是程序内存泄漏的原因,那么就该升级内存或者把耗内存的任务迁移到其他机器。
free:空闲的物理内存的大小。
buff:缓冲区。
cache:高速缓存,是位于CPU于主内存间的一种容量较小但速度很高的存储器。
si:每秒从磁盘读入虚拟内存的大小。如果大于0,则表示机器的物理内存不足或者内存泄漏了,要查找耗内存进程解决掉。
so:每秒虚拟内存写入磁盘的大小。如果大于0,情况同上。
bi:块设备每秒接收的块数量。
bo:块设备每秒发送的块数量。例如读取文件,bo就要大于0。bi和bo一般都要接近0,否则就是I/O过于频繁,需要调整。
in:每秒CPU的中断次数,包括时间中断。
cs:每秒上下文切换次数。例如调用系统函数,就要进行上下文切换,如线程的切换,进程上下文切换等,这个值越小越好,太大了,就要考虑调低线程或者进程的数目。上下文切换次数过多表示CPU大部分浪费在上下文切换上,导致CPU没有被充分利用,这是不可取的。
us:用户CPU时间。
sy:系统CPU时间。如果该值太高,则表示系统调用时间长,可能是I/O操作频繁。
id:空闲CPU时间。一般来说,id+us+sy=100.
wa:等待I/OCPU时间。
(2)CPU密集程度命令:ps和top
ps -ef (获取最近使用CPU调试密集的用户进程)
c:进程近来使用CPU时间。
TIME:从进程启动以来使用CPU的总时间。(以分钟和,秒为单位)
%CPU是从进程启动以来分配给该进程的CPU时间百分比。
%CPU=(进程CPU时间/进程持续时间)*100%
top (实时监控系统资源使用情况)
(3)监控内存最常用命令free,vmstat,top等
total:物理内存的总大小。
used:已使用的物理内存大小
free:空闲的物理内存大小
shared:多个进程共享的内存大小
buff/cached:磁盘缓存的大小
Mem:代表物理内存使用情况
Swap:表示交换空间内存使用情况。
评估指标 | 采集频率 | 指标说明 |
---|---|---|
IHS端口连接数 | 1分钟 | 反映HTTP连接数 |
IHS httpd 进程数 | 1分钟 | 反映HTTP进程数 |
WAS APP SVR端口连接数 | 1分钟 | 反映APP SVR并发量 |
WAS APP SVR线程数 | 3分钟 | 反映APP SVR并发量 |
WAS APP SVR数据源连接池使用数 | 2分钟 | 反映JDBC连接池使用情况 |
WAS JVM Heap 平均大小 | 压力测试后统计 | 反映JVM内存使用率 |
WAS JVM GC 总次数 | 压力测试后统计 | 反映JVM内存健康度 |
WAS JVM GC 总时长 | 压力测试后统计 | 反映JVM内存健康度 |
WAS APP SVR 程序大对象 | 压力测试后统计 | 反映JVM内存健康度 |
主机资源 | 测试期间,CPU,I/O,MEMORY资源是否形成瓶颈 |
---|---|
SQL语句 | AWR 中是否有问题SQL |
TOP 5 TIMED EVENT | AWR 中Top5等待事件中是否有异常等待事件 |
软件
主要分析具体事务执行时间,尤其是并发用户部分,分析哪些事务执行慢,然后可以分析执行较慢的代码,针对网页可以分析具体的页面元素执行情况。
服务器
着重分析硬件的执行参数,如CPU,硬盘,内存,中断等情况,尤其要注意对这些参数进行综合分析,因为各个参数之间往往会互相影响。
网络
网络性能分析要结合服务器和测试目标软件,通常网络传输慢会有软件和服务器方面的原因,甚至有时候会有客户端方面的原因。
官网下载:https://www.oracle.com/java/technologies/downloads/#jdk17-windows
双击安装,点击下一步,记住安装的地址,其他操作按指示傻瓜式点击
配置环境变量
变量:JAVA_HOME C:\Program Files\Java\jdk-17.0.5
path:%JAVA_HOME%\bin
cmd中输入命令:java -version 验证JDK安装成功
官网下载:https://jmeter.apache.org/download_jmeter.cgi
下载解压即可,无须安装
bin目录:存放可执行文件和配置文件
jmeter.bat:windows的启动文件
jmeter.log:日志文件
jmeter.sh:linux的启动文件
jmeter.properties:系统配置文件
jmeter-server.bat:windows分布式测试要用到的服务器
jmeter-serve:linux分布式测试要用到的服务器配置
看不到后缀名的解决办法:
docs和extras目录:主要存放jmeter的API帮助文档
lib目录:该目录用来存放Jmeter依赖的jar包和用户扩展所依赖的jar包
language=zh_CN # 修改成中文
sampleresult.default.encoding=UTF-8 # 编码修改成UTF-8
server.rmi.ssl.disable=true # 电脑中没有安装 SSL,JMeter 在第一次打开报错的话可修改这项
CookieManager.save.cookies=true # 模拟含 Cookie 的 HTTP 请求,可修改这项
(1)双击jmeter.bat打开
(2)右键【测试计划】添加【线程组】
(3)右键【线程组】添加【HTTP请求】
(4)【HTTP】请求填写相关请求数据
(5)右键【线程组】添加【察看结构树】
(6)点击运行,在【查看结果树】看结果
元件 | 含义 |
---|---|
取样器 | 往服务器发送请求,类似于自动化脚本中的发送请求。 |
前置处理器 | 对要发送的请求进行预处理,类似于自动化脚本中的参数化。 |
后置处理器 | 对收到的服务器的响应数据进行处理,类似于自动化脚本中获取响应中特定字符的操作。 |
断言 | 将收到的响应结果于预期结果做对比,与自动化测试中的断言一致。 |
定时器 | 等待一段时间,类似于自动化测试脚本中的sleep。 |
测试片段 | 封装基本功能的代码块,不单独执行,需要脚本进行调用,类似于自动化中封装的函数。 |
配置元件 | 进行测试环境和测试数据的初始化,类似自动化脚本中的setup。 |
监听器 | 查看测试脚本运行的结果和日志,类似于自动化测试脚本中的测试报告。 |
线程组:用户模拟多线程,一个线程代表一个测试用户。
取样器(请求)和逻辑控制器必须依赖线程组才能使用
线程组可以添加多个,多个线程组可以并行或串行
线程组下可以添加其他元件组件
(1)在Jmeter中,元件的作用域是根据测试计划的树形结构中元件的父子关系来确定的。
(2)元件中取样器是核心,其他组件都是以取样器为核心运行的,组件添加的位置不同,生效的取样器也不同。
(3)取样器都是一个独立的请求,不和其他元件相互作用,因此不存在作用域。
(4)逻辑控制器只对其子节点中的取样器和逻辑控制器作用
(5)其他六大元件,除取样器和逻辑控制器元件外,如果是某个取样器的子节点,则该元件对其父节点起作用;如果其父节点不是取样器,则其作用域是该元件父节点下的其他所有后代节点(包括子节点,子节点的子节点等)。
(1)配置元件(相当于自动化测试中的初始化)
(2)前置处理器
(3)定时器
(4)取样器
(5)后置处理器
(6)断言
(7)监听器
注意:
1.jmeter元件执行顺序跟自动化脚本执行顺序差不多,可以按照自动化脚本的运行顺序来记忆。
2.前置处理器,后置处理器,断言等元件功能只对取样器起作用(如果在它们的作用域内没有任何取样器,则不会被执行)。
3.如果在同一作用域范围内有多个同一类型的元件,则这些元件按照它们在测试计划中的上下顺序依次执行。
一个线程下有多个HTTP请求,请求的web服务器内容是一样的,避免每创建一个HTTP请求,就重复填写web服务器信息,可添加HTTP请求默认值。
取值的顺序:HTTP请求本身设置的值,HTTP请求下的HTTP请求默认值设置的值,线程组下的HTTP请求默认值设置的值。
HTTP只用填写下面的路径
(1)【测试计划】右键添加HTTP代理服务器
(2)确认HTTP代理服务器端口未被占用
cmd中输入命令:netstat -ano | findstr 8888查看端口是否被占用,如果被占用了,可随便修改HTTP代理服务器端口。
(3)设置HTTP代理服务器
(4)浏览器设置代理
设置-》高级-》打开您计算机的代理设置
(5)点击HTTP代理服务器中的启动,弹出的窗口提示点是。然后开始去系统页面操作,Jmeter会记录下系统中的请求。
(6)录制完成,点击停止,将浏览器的代理关掉,这样才能使用浏览器访问其他网页。
如果需要循环访问一个请求10次,要求每次请求发送不同的参数值,这个时候需要参数化测试,常用的有用户定义变量和csv方法。
关联主要用于解决性能测试中多个接口之间的依赖关系,一般我们可以通过jmeter的后置处理器进行提取。
情景一:正则表达式提取器提取一个值
提取HTTP请求1响应内容的title,将title作为HTTP请求2的参数
情景二:正则表达式提取器提取多个值,需要添加调试取样器查看多个值的变量名
提取HTTP请求1响应内容的校区,返回很多值,选其中一个值作为HTTP请求2的参数
beanshell是一个小型,免费,可嵌入的Java源代码解释器,具有用java编写的对象脚本语言功能。
常见的beanshell组件:
BeanShell Timer(定时器)
BeanShell PreProcessor(前置处理器)
BeanShell Sampler(采样器)
BeanShell PostProcessor(后置处理器)
BeanShell Assertion(断言)
BeanShell Listener(监听器)
下载数据库连接驱动包
if控制器
用来控制它下面的测试元素是否运行
例如:定义一个“用户定义的变量“name,当name等于百度,执行百度请求,当name等于qq,执行qq请求。
事务控制器
Jmeter默认把每一个请求都统计成一个事务,但有时候我们根据业务需求,会把多个操作系统计成一个事务,Jmeter通过事务控制器来完成,整个事务中所有请求都成功了事务才算成功,否则结果就是失败。
例如:事务控制器下面创建多个HTTP请求
添加方式:测试计划-》线程组-》HTTP请求-》右键添加定时器-》Synchronizing Timer
相当于一个储蓄池,累积一定的请求,当在规定的时间内达到一定的线程数量,这些线程会在同一个时间点一起并发,所以可以用来做大数据量的并发请求。
例如:模拟1000个用户同时访问QQ首页,统计高并发情况下平均响应时间以及错误率。
当同步定时器的模拟用户组数量无法被线程数量整除时,则剩余线程将一直处于挂起状态无法执行。
同步定时器的超时时间设置不能短语线程Ramp-up的时间,否则一直都无法达到模拟用户组数量,导致无法形成并发的效果。超时时间设置为0,默认是没有超时时间的。
在使用Jmeter进行性能测试时,如果并发数比较大(比如项目需要支持10000并发),单台电脑的(CPU和内存)可能无法支持,这时就可以使用Jmeter提供的分布式测试的功能。
在进行压测的时候不要使用界面来执行,界面会占用资源,一般是在Linux上运行的
先配置jmeter环境变量:
新增变量JMETER_HOME jmeter路径
Path里面加上%JMETER_HOME%\bin
测试计划存放路径下打开cmd
生成报告的命令:jmeter -n -t 测试计划名 -l http.jtl -e -o report
-n 以非GUI形式运行Jmeter
-t jmx脚本路径
-l 运行结果保存路径(.jtl),此文件必须不存在,路径+文件名
-e 在脚本运行结束后生成html报告
-o 用于存放html报告的目录,只能是一个空目录
如果已经有之前运行报告命令生成的jtl文件,也可以直接使用jtl文件生成报告。
执行命令:jmeter -g 测试计划名 -o report