关于压测的一些思考

单机压测能较准确的得出被压服务的极限容量情况

• 单机压测能够排除外部链路、网络等因素，得出被压服务单机性能极限情况。服务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等指标监控是否获取。
  可以从以上若干个方面考虑评价某次大型链路压测的仿真度。