基于上述性能工程系列的前几篇讲解，我们根据前面讲的结合前期性能模型（TPS - 并发数模型、资源配置模型）与反模式库，定位瓶颈点并针对性优化。
在性能压测中，TPS（Transactions Per Second，每秒事务数）未达预期（如目标 3 万 TPS，实际仅 1.5 万）是最常见问题，其本质是 "压测压力未有效传递至业务系统，或系统某环节无法承载当前压力，又或环境，工程，网络，DB，中间件困素引起"，此时需基于 "端到端链路拆解" 思路，结合前期性能模型（TPS - 并发数模型、资源配置模型）与反模式库，定位瓶颈点并针对性优化。
一、先明确：TPS 的核心影响逻辑
TPS 是 "并发用户数、单次事务耗时、系统承载能力" 三者的平衡结果，公式参考前期 TPS - 并发数模型：
TPS = 并发用户数 × 60s / 单次事务平均耗时
例：30 万并发用户，单次事务耗时 200ms，理论 TPS=9 万；若实际 TPS 仅 1.5 万，说明 "单次耗时变长（如升至 400ms）" 或 "系统无法支撑 10 万并发（如并发 5 万时 CPU 已打满）"等情况 ，都 可以从以下几个维度去排查。
二、5种排查方向：TPS 上不去的核心原因与排查方法
影响因素1：压测环境问题 ------"压力没打进去"
压测环境自身的限制会导致 "压力无法有效施加到业务系统"，常见问题如下：
影响因素2：业务系统资源瓶颈 ------"硬件扛不住"
业务系统的 CPU、内存、磁盘 I/O 等硬件资源达到上限，会直接限制 TPS 提升，需结合前期 "资源配置模型"（如 CPU 利用率≤80%、内存≤70%、磁盘 IOPS≤80%）排查：
影响因素3：应用架构瓶颈 ------"代码 / 中间件问题"
应用层的代码逻辑、线程池配置、中间件（Redis、MQ）性能会直接影响事务处理效率，需结合前期 "反模式库"（如线程池一刀切、缓存穿透）排查：
影响因素4：数据层瓶颈 ------"数据库瓶颈"
数据库（MySQL、MongoDB 等）是压测中最常见的瓶颈点，尤其是高并发写入 / 查询场景，需结合前期 "分库数模型""慢 SQL 反模式" 排查：
影响因素5：压测方案问题 ------"测试设计不合理"
压测方案未贴合业务实际或未参考性能模型，会导致 "TPS 无法反映真实能力"，需结合前期 "压测计划模型" 排查：
三、排查 TPS 瓶颈的 "行业法则"（结合平台工具）
第一步：定位 TPS 拐点
- 用平台 "压测趋势模块" 查看 "并发数 - TPS - 响应时间" 曲线：
- 若并发增加，TPS 增长缓慢且响应时间变长→资源 / 应用瓶颈；
- 若并发增加，TPS 突然下降→系统崩溃（如内存溢出、限流触发）。
第二步：全链路指标监控
- 打开平台 "全链路监控面板"，同步查看：
- 资源层：CPU、内存、IO（是否达上限）；
- 应用层：线程池、接口耗时、GC（是否有异常）；
- 中间件：Redis 命中率、MQ 堆积（是否有瓶颈）；
- 数据层：DB 连接数、慢 SQL、分表 QPS（是否存在瓶颈）。
第三步：针对性压测验证
- 若怀疑某环节（如 Redis），单独压测该组件（如用 redis-benchmark 压测 Redis），验证是否为瓶颈；
- 若怀疑代码，用平台 "代码 profiling 工具" 定位高耗时代码（如某方法占比 60%）。
四、案例应用
压力未有效施加
4.1实际案例
发生的项目其压测的链路为商品下单链路，下单链路活动会期间目标处理能力为30WTPS，压测机（阿里云上海区等就近区域），业务机（阿里云杭州区），跨公网部署，接口单次请求大小 10KB，有缓存，也会依赖 DB 查询（响应时间 90ms）。
4.2问题现象
TPS 最高仅 12W（达目标 20%），随压测时间延长，TPS 逐步下降；压测机 CPU 使用率 80%、内存使用率 40%（仍有剩余资源）；业务机 CPU 使用率 20%、DB 查询量 1200 次 / 秒（压力未完全传递）；事务响应时间中 "网络耗时" 占比 70%（单次网络耗时 140ms，业务耗时 100ms）。
4.3 排查具体步骤
步骤 1：拆解事务耗时，定位损耗环节
a. 添加 JMeter 耗时监控：
在 "HTTP 请求" 下添加 "Transaction Controller"，分别统计 "网络耗时"（连接建立 + 数据传输）与 "业务耗时"（接口处理）；结果显示：单次事务总耗时 200ms，其中 "网络耗时 140ms"（占比 70%），"业务耗时 100ms"（占比 30%）。
网络延迟与带宽验证：压测机 ping 业务机：延迟 80ms（公网跨区域正常范围，但累积损耗大）；计算网络吞吐量：单请求 10KB，TPS 12W 时，吞吐量 = 120000×10KB=1200MB/s=96Mbps（远低于公网带宽 100Mbps 上限，非带宽瓶颈）；抓包分析（tcpdump）：发现 2% 的数据包重传（公网波动导致，进一步增加延迟）。
步骤 2 ：验证同网络环境下的压力传递
临时迁移压测机：将压测机迁至杭州区（与业务机同区域），重新压测；结果：网络延迟降至 10ms，单次网络耗时 10ms，TPS 立即升至 125000（达目标 103%），证明跨公网是压力损耗主因。
4.4 解决实施步骤
优先同区域部署压测机：长期方案：压测机与业务机同机房 / 同云区域（如均为阿里云杭州区），网络延迟从 100ms 降至 10ms，消除跨区域损耗；优化请求大小，减少网络传输：接口返回数据压缩：开启 Gzip（请求大小从 10KB 降至 2KB）；
字段裁剪：定单列表接口仅返回 "id、name、price，orderNo" 核心字段（删除冗余字段，进一步缩减请求大小）；
增加压测机数量，抵消网络延迟：
临时方案（无法迁移压测机时）：新增 1 台同配置压测机，双机分布式压测，TPS 从 1200 升至 2300（接近目标 80%）。
4.5 效果验证
同区域部署后，TPS 达 320000（目标 103%）；事务响应时间降至 70ms（网络耗时 10ms，业务耗时 60ms）；压测机 CPU 使用率升至 80%、业务机 CPU 使用率升至 75%（资源充分利用）；数据包重传率降至 0.1%（同区域网络稳定性提升）。
业务系统资源瓶颈
未完，待续
应用架构瓶颈
未完，待续
DB层瓶颈
未完，待续
压测方案问题
未完，待续