负载测试核心是控制变量、统一口径、聚焦可比指标，通过基线压测对比架构优化前后P95响应时间、TPS和CPU利用率三类关键指标，并结合调用链与资源监控归因根因，排除外部干扰确保结论可信。
负载测试通过基准压测对比架构优化前后的性能差异，核心在于“控制变量、统一口径、聚焦可比指标”。不是简单跑两次压测看数字变没变，而是构建一套可复现、可归因的对比体系。
明确统一的测试基线与场景
基准压测的前提是前后两次测试环境高度一致：相同硬件配置（或等效云实例规格）、相同中间件版本（如Redis 7.2、MySQL 8.0）、相同监控采集粒度（如Prometheus每10秒抓一次CPU/内存/连接数）。关键业务路径必须锁定——比如只测“用户登录→获取首页数据→下单”这一链路，且请求参数、数据集（如用同一套10万用户ID+商品SKU）完全一致。并发模型采用阶梯式加压（如50→200→500→1000并发），持续时间不少于15分钟，排除冷启动干扰。
聚焦三类可量化、有业务意义的对比指标
不堆砌数据，只盯三个维度：
- 响应质量：重点看P95响应时间（而非平均值），它反映绝大多数用户的实际体感。例如订单创建接口从480ms降至210ms，说明高延迟尖刺被有效削平；
- 系统吞吐能力：对比Requests/sec或TPS（每秒事务数）。迁移后从892 req/s升至2156 req/s，说明单位时间处理能力翻倍以上；
- 资源效率：CPU平均利用率从78%降至62%，意味着同样负载下系统更“轻量”，留出余量应对突发流量，也降低扩容成本。
结合调用链与资源监控定位差异根因
数字变化只是表象，必须穿透到执行层才能确认是否真由架构优化驱动。例如响应时间下降，需验证是否源于：
- 数据库慢查询减少（通过APM工具看SQL耗时分布）；
- 跨服务调用链路缩短（如原单体内方法调用变为微服务间异步消息，P99网络等待消失）；
- 资源争用缓解（如连接池排队数从平均12降为0，线程阻塞时间归零）。
若指标改善但监控未显示对应环节优化，则可能是外部因素（如网络抖动减少、底层宿主升级），不能归功于架构改动。
排除干扰项，确保结论可信
常见干扰包括：压测客户端自身瓶颈（CPU打满导致发不出请求）、被测服务依赖的第三方接口限流、测试期间其他定时任务抢占资源。建议每次压测前做“空载验证”——不发业务请求，只开监控看基础资源波动；压测中同步记录上下游依赖状态（如Kafka积压量、下游服务错误率），一旦发现异常，该轮数据作废。
