🏦 核心系统性能测试实战案例

📌 案例概述

某银行核心账务系统大版本升级后，压测发现TPS从预期的5000骤降至2200，且P99响应时间从1.2秒飙升至4.8秒。项目组需要在2周内定位瓶颈并达到上线标准。本案例完整还原了从问题发现→根因分析→逐层调优→最终验证的全过程。

📋 案例背景

• 系统名称：核心账务系统（记账、对账、总账模块）
• 技术栈：Java 11 + Spring Boot 2.6 + Oracle 19c RAC + WebLogic
• 部署架构：4台应用服务器（32C/64G）+ 4节点Oracle RAC + 负载均衡F5
• SLA目标：TPS≥5000，P95≤500ms，P99≤1s，错误率≤0.01%
• 测试环境：准生产环境（配置与生产1:1）

🔍 测试过程

第一轮：基准测试（发现问题）

以1000并发执行记账交易混合场景，结果：TPS=2200（目标5000），P50=380ms，P99=4800ms，CPU使用率仅45%。关键发现：TPS在并发700时达到拐点、P99出现周期性尖峰。

第二轮：数据库层排查

分析AWR报告发现Top SQL是一条记账事务的UPDATE语句，每次执行需要平均850ms。进一步分析执行计划——发现统计信息过旧导致优化器选错了索引。更新统计信息后，该SQL执行时间降到12ms。TPS提升至3200但仍不达标。

第三轮：连接池排查

TPS在3200后不再增长，检查WebLogic连接池——最大连接数设置为50。根据并发模型计算需要至少120个连接。调大连接池至150，TPS提升至4200。

第四轮：JVM调优

P99仍然偏高（3.2秒），GC日志显示Young GC频率20次/分钟但每次仅20ms，Full GC每小时2次每次3秒——恰好对应P99毛刺。调整-XX:NewRatio=2 -XX:SurvivorRatio=8，增大年轻代比例。TPS达到4900，P99降至1.5s。

第五轮：最终验证

稳定性测试8小时：TPS均值4850，P50=280ms，P95=520ms，P99=1.1s，错误率0.007%。结论：各项指标基本达标，准出通过。

📊 调优效果对比

💡 关键经验

1. 数据库是性能问题第一优先级——本案例80%的瓶颈在数据库层（统计信息+连接池）
2. 分层排查、一次只改一个变量——5轮调优每轮只改一个层面的参数，可清晰判断效果
3. P99尖峰往往对应GC——看到周期性P99毛刺，先检查GC日志
4. 基线对比必不可少——每一轮调优前后记录数据，用数据说服开发和运维接受变更