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