性能测试基础知识
2024-07-30 19:40:40 0 举报
AI智能生成
各性能指标基础知识
作者其他创作
大纲/内容
性能优化过程
1、性能指标
指标依据
规模
当前规模
预测规模
当前系统性能现状、性能目标
资源指标
CPU、内存、IO、网络
系统指标
用户并发数
吞吐量、tps
响应时间
错误率
用户体验指标
首屏时间
白屏时间
完全加载时间
2、性能测试
性能基线
确定系统对RT和错误率的容忍度,通过压测推算系统能支持的最大QPS、并发量等性能指标。
性能瓶颈预测
通过压测了解系统的负载能力,暴露系统性能问题并修复。
性能回归测试
针对已上线系统或者性能指标明确的系统,在涉及影响性能的改动时进行回归测试,确保满足预期。
稳定性测试
在一定压力下,系统能否长时间稳定持续的提供SLA保障,一般考虑将压力设定为业务峰值的80%,持续施压。
性能压测策略
大量数据 压测
资源指标
指标参数
CPU
内存
网络
IO
单实例指标参数
2g1c
4g2c
8g4c
系统指标
耗时
网络耗时
系统逻辑耗时
性能基线
测试维度
测试系统指标结果
测试资源指标结果
并发测试
指标依据
规模
当前规模
预测规模
业务量
日均业务量
高峰期业务量
极限业务量
周期场景
日单量统计
周单量统计
月单量统计
资源指标
CPU
内存
网络
IO
系统指标
并发用户数
吞吐量
响应时间
错误率
TPS
性能基线
测试维度
测试系统指标结果
测试资源指标结果
3、性能监控
监控--》分析--》优化
监控预警机制
指标监控
预警
预警阈值
报警通知
4、优化措施
业务流程优化
代码优化
异步
可以异步处理的尽量异步化
异步rpc
消息队列
合并和拆分
大量小连接做合并处理
小狼大连接做拆分处理
业务规则合并
并行/并发
相同任务串行改并行
不同任务串行改并发
缓存:空间换时间
减少数据库及服务调用IO
降低数据库压力
降低对上有服务的依赖
数据结构
使用合适的数据结构
数据结构容量预初始化
慢sql
批操作sql
索引
字段
代码规范
日志打印规范
代码逻辑规范
高性能架构
SQL
NoSQL
缓存
并发
负载
基础理论
性能测试的定义
通过一定的手段,在多并发的情况下,获取系统的各项性能指标,验证被测系统在高并发下的处理能力、响应能力、稳定性等,能否满足预期需求。定位性能瓶颈,排查性能稳重,保障系统的质量,提升用户体验。
性能测试的目的
应用程序是否能够很快相应用户的要求?
应用程序能承载多大的业务量
应用程序能否7*24小时运行
是否能够确保用户在真正使用软件时获得舒服的体验
性能测试的原理
基于协议,基于代码
模拟用户,多线程
模拟多用户的真实使用场景
性能指标
响应时间RT
网络传输的总时间+业务处理时间
响应时间的大小直接反应了系统的快慢,响应时间最小,系统在越快。
执行一个请求开始到最后收到响应数据所花费的总体时间
并发数/虚拟用户数
压测设置的线程数
top响应时间
将所有请求的响应时间按小到大排序,计算指定比例的请求都是小于某个时间。
该指标统计的是大多数请求的耗时。例如发送100条请求,设置top95,则选取所有请求中95%请求的响应时间
该指标统计的是大多数请求的耗时。例如发送100条请求,设置top95,则选取所有请求中95%请求的响应时间
成功率
请求响应的成功率
业界常用99.9%和99.99%
PV
页面/接口的访问量
UV
页面/接口的每日唯一访客
吞吐量QPS
网络中上行和下行的流量总和,吞吐量代表网络的流量,tps越高,吞吐量越大
集合点
集合点是为了增加瞬间并发压力的一种机制,在脚本在增加一个标记,所有虚拟用户执行到标记处会进行等待,等所有用户到达后,再同时执行下一步操作
适用场景:业务场景是高并发类型,例如秒杀、抢购等
缺点:增加集合店后,系统的平均压力会降低
指标监控
操作系统
cpu,内存,网络IO,磁盘
中间件
连接数,长短连接,使用内存,消息队列积压
应用层
线程状态、JVM参数、GC频率、锁
数据层
连接数、锁、缓存、内存、sql效率
有点:会产生一种瞬时高并发
测试流程
1、需求收集
有明确需求
无明确需求
pv模型,数据明显
8-2原则计算
跟客户沟通的出一些性能需求
制作性能模型的出最大并发数和最佳并发数
内部系统:并发数 〉 用户总数*30%
响应时间要求:2-5-8原则
2、场景设计
并发数
持续时间
门型
并发用户数突然间从0变成N,持续一段时间,又从N变成0。(适应于压力测试,目的在于检测服务器的抗压能力,如果无法抗住压力,服务器表现出来的反应)
拱型
并发用户数慢慢从0变成N,整个过程具备节奏感,可监控跟踪该段时间内,随着并发用户数的增加(Ramp Up),相关性能指标到的变化趋势。与之对应的,从N变成0的过程(Ramp Dowm),也应该如此。(适用于负载测试,也适用于指标分析,以及系统性能预测试)
复杂场景
模拟真实服务器访问情况,不停的在Ramp Up , Duration , Ramp Dowm 之间切换,场景运行图像类似于高低起伏不同的波浪线,这类场景运用较少,因为需要大量的历史数据作为支撑,通常不适用于对未上线的系统进行设计
全链路
3、准备测试脚本
python多线程
jmeter
loadrunner
K6
ab、siege等
4、测试执行
代码执行
压测工具
监控
相关日志:异常,内存溢出等
服务器资源
jstack,top,vmstat
zabbix,Prometheus
客户端
客户端资源不够回影响测试工具自身的性能,影响请求的发送
监控执行过程的错误率
5、结果分析
指标详细分析
jvm监控
内存监控
线程监控
现状和趋势
性能测试自动化、平台化
测试工具多样化、开源、二次开发
高并发下验证功能正确性
线上线下相结合,线上发现问题,线下调优
web端性能测试
系统架构
B/S架构
页面展示流程
1. 下载页面上的静态资源,html、css、js、图片等
性能取决于cdn服务器或者web中间件对静态资源的处理能力、网络带宽的限制、静态资源size是否合理等
2. 浏览器对静态资源进行渲染
浏览器的本地行为,渲染的性能取决于浏览器的性能,或者是本地电脑的cpu、显卡的性能,跟web系统没有关系
3. 当静态资源加载完毕/用户执行某种操作后,执行js脚本,调用接口获取动态数据
服务端接口的性能范畴
测试手段
chrome和Firefox自带的devtool功能,可以查看页面各组件的下载时间和size
第三方工具自动检查,如YSlow
操作、环境安装
app端性能测试
设备性能
网络性能
网络抖动
网络上接受信息存在延迟
代码需要有处理抖动的逻辑,因此也需求被我们测试到
数据包丢失
在数据包完全丢失的情况下,该app能够重新发送请求,或生成警报
最好有适当的信息显示,或者提示用户进行重试
网络速度
在wifi、2g、3g、4g网络进行测试
不同网络之前来回切换
api性能
0 条评论
下一页