单机压测能较准确的得出被压服务的极限容量情况
- 单机压测能够排除外部链路、网络等因素，得出被压服务单机性能极限情况。服务owner可以根据单机极限值、服务目标qps扩容。
- 单机压测不会对上下游的性能造成瓶颈，所以能保证服务性能的置信度
压测过程理解
压测过程思路可以向质量保障方向靠拢。粒度由小及大。
单机单接口---单机多接口---集群压测---链路压测
- 单机压测可以基本保证在上下游资源充足的情况下，获知当前服务能承载的极限qps值。在链路压测之前暴露更多的问题并修复，为集群容量提供数据支持。
- 以此类推，链路上的服务如都能够做到单机压测，极大的保障了服务调用链路上容量的稳定性，降低链路压测暴露的问题。
需要⚠️：单机压测的前提是线上机器的配置都是相同的，如配置不同，可能机器性能差距较大，从而根据单机性能极限扩容的服务容量并不可靠
常见的性能问题
- 网络带宽 对于推荐业务类的服务，其请求的size是巨大的，达到0.5M。所以需考虑到网络带宽的限制。
- 下游拖垮 链路压测经常出现的问题就是调用链路中某些服务性能达到瓶颈，会影响整个链路的可用性。所以链路压测时应密切关注调用链上各服务的可用性情况。
- 机器本身性能劣化 年久失修
- 数据库不当操作 如慢查询/数据库连接池不释放
- 业务逻辑复杂 如拉取feed流一般会拉取好几百个，响应体比较大；或者有大量的写入操作。
- java线程池被打满，应合理设置
压测模型
image.png
压测环境准备
- 压力机资源
- 被压测系统
- 依赖资源（压测数据，第三方依赖）
压测策略准备
- 压测需要达到的目标（比如期望达到的QPS，稳定性要求等）
- 压测场景（业务场景选取、组合）
- 压测策略（逐步加压、脉冲、并发量等）
压测执行闭环
- 压力机压测
- 分析程序收集压测数据（RT，QPS/TPS，成功率，错误，内存，IO等）专业的工具基本涵盖
- 分析压测报告
- 确定优化计划
- 反馈到压测系统或者调整压测策略
线上流量回放压测模型
⚠️不是引流压测模型
image.png
有如下优点：
- 仿真度高（主要体现在 a.真实的请求数据 b.真实的线上环境 c.真实的业务场景）
- 按需控制压测流量
- 成本低（无需搭建压测环境）
如何评价某次大型压测的仿真度
链路维度
- 本次链路压测覆盖了多少个服务、多少个方法。
接口维度
- 比如说本次大型活动链路压测覆盖到活动相关的多少个接口，覆盖率是多少。
业务场景维度
- 核心业务链路如推荐系统中的：同城访问、热门页访问、关注页访问、个人主页等
硬件资源使用维度
- 如被压服务的cpu.busy. mem.used. net.in. net.out等指标监控是否获取。
可以从以上若干个方面考虑评价某次大型链路压测的仿真度。
