文章目录
- 什么是性能测试
- 性能项目分类
- 性能测试流程
- 在这里插入图片描述
- 场景分类
- 基准场景
- 容量场景
- 稳定性场景
- 性能指标
- 性能指标
- 分布式压测
日期:2024年4月19日
从今日起开始系统更新性能测试学习笔记,一方面督促自身的学习进度,另一方面提高专注力,保持日更。
什么是性能测试
性能测试是针对系统的性能指标,建立性能测试模型,制定性能测试方案,制定监控策略,在场景条件下执行性能测试,分析判断性能瓶颈并调优,最终得出性性能结果来评估系统的戏能指标是否满足既定数。
性能项目分类
- 新系统性能测试类:一般要求测试出系统的最大容量,不然上线心里没底
- 旧系统新版本性能测试类:一般是和旧版本对比,只要性能不下降旧可以根据历史数据推算容量,一般对调优要求不高
- 新系统性能测试优化类:这样的系统不仅要测试出最大容量,还有调优到最好的需求
对性能团队的职责定位:
- 性能验证:针对给定的指标,只做性能验证。
- 性能测试:针对给定的系统,做全面的性能测试,可以得到系统最大容量,但不涉及调优
- 性能测试+分析调优:针对给定的系统,做全面的性能测试,同时将系统调优到最优状态
性能测试流程
实际情况不会像这张图描绘:
老师理解的部分:
- 重负载区的资源饱和和tps达到最大值之间在很多时候不是在同样的并发数之下的,比如说,当cpu资源使用率达到100%之后,随着压力的增加,队列慢慢变长,但是由于用户数增加的幅度会超过队列长度,所以tps依然会增加,也就是说资源使用率达到饱和之后还有一段时间tps才会达到上限
- 大部分情况下,相应的曲线都不会像这个图中画的这样陡峭,并且也不一定是在塌陷区突然上升的,更可能是在重负载区突然上升
- 吞吐量曲线,不一定会出现下降的情况,在有些控制比较好的系统中会维持水平
- 最优并发数这个点,通常只是一种感觉,而没有绝对的数据来证明,在生产运维的过程中,其实我们大部分人会更加谨慎,而不会定这个点为最优并发,而是更靠前一些
- 最大并发数这个点,就完全没有道理了。性能都已经衰减了 ,最大并发数肯定是在更靠前的位置,应该更加理智的关注tps
- 这个图没有考虑到一些锁或线程配置不合理的场景,而这类场景又比较常见,也就是我们说的tps上不去,资源用不上。这个图默认了一个前提,只要线程能用得上去,资源就会蹭蹭往上长。
【实际中更加合理的图】
A点:最优响应时间点
C点:tps达到最大值,不报错
D点:响应时间很高,tps已经下降,性能衰减的过程
E点:表达超时的一个过程
B点:应该是业务部门给出指标的一个点
场景分类
- 基准场景(单交易容量场景)
- 验证单业务用户场景的执行
- 找到单业务的最大tps和最优响应时间
- 容量场景(递增场景,最大tps,最快响应时间场景)
- 关键点:递增
- 稳定性场景(运维最好的状态)
- 不必拿最大的tps的80%来运行
- 要考虑运维周期之间的业务累计量
- 异常场景(运维中异常的处理)
- 保持tps的稳定性
基准场景
容量场景
稳定性场景
场景 | 作用 |
---|---|
基准性能场景 | 也可称为单交易容量。即将每一个业务都压到最大tps,从而为后续场景做数据对比 |
容量性能场景 | 也可以称为混合容量性能场景。即将所有业务根据比例加到一个场景中,在数据、软硬件环境、监控等的配合之下,分析瓶颈并调优的过程 |
稳定性能场景 | 核心就是时长,在长时间的运行之下,观察系统的性能表现,分析瓶颈并调优的过程 |
异常性能场景 | 显然就是异常的定义最为重要。异常手段有:宕主机、宕应用、宕网卡。随着云基础架构,还有宕容器、缓存、虚拟机、队列、流控、熔断等等 |
性能指标
简写 | 英文全称 | 含义 |
---|---|---|
RT | response time | 响应时间,包括请求request和response time |
HPS | hits per second | 每秒点击数 |
TPS | transactions per second | 每秒事务数 |
QPS | queries per second | 在mysql中指每秒sql数 |
RPS | requests per second | 每秒请求数 |
CPS | codes for second | 在http协议中,cps偶有提及,指的是http返回码每秒 |
PV | page view | 页面浏览量 |
UV | unique vistior | 独立访问者 |
IP | internet protocol | 独立ip数 |
throught | 吞吐量 | |
IOPS | input/output operations per second | 描述磁盘 |
性能指标
分为:业务指标和技术指标
- 业务指标:业务部门给出的指标,例如多少人同时使用,业务场景分布情况
- 技术指标:时间指标(接口响应时间,业务响应时间,用户级别响应时间)、容量指标(接口容量、业务容量)、资源利用率指标(操作系统、jvm等)
在线用户数根据并发度计算出tps 再根据响应时间,计算出并发线程数
TPS=(1/avg(RT))*threadnumber
假设在线用户有10000个,并发度为5%,那么tps就是500tps,要求响应时间100ms,那么并发数就是50。