主题
项目实战：Kingbase 迁移后性能压测
用到的技术栈：Apache JMeter 5.6.3（命令行
-n模式）+ Kingbase 8 JDBC + kbbench 初始化工具 一句话机制：国产数据库迁移后「能不能上线」不能靠厂商测试数字，只能靠统一口径下的自有 JDBC 压测——用 JMeter 连接池压出吞吐/时延曲线，把瓶颈与 SLA 达标情况落到可量化的通过率上。
业务背景（已脱敏）
- 场景：系统后端数据库由 PostgreSQL（开源）迁移至 Kingbase（人大金仓 V8）后，需压测验证迁移未引入性能退化、确认具备上线条件。
- 规模：5 个压测场景、累计约 590 万请求样本；20 并发稳定吞吐约 1.3 万次/秒，整体错误率约 0.003%。
- 约束：压测机为 Linux 服务器、只能无 GUI 命令行模式；国产库需使用专用 JDBC 驱动；测试表需先用 kbbench 初始化。
架构 / 关键设计
链路：JMeter 每线程循环执行 ① 主键等值查询（Prepared Select）→ ② 主键定点更新（Prepared Update）两条 JDBC 采样器，读写 1:1 混合；单连接池 + DurationAssertion（本例 200ms）作 SLA 断言。
场景矩阵（并发/时长/原型）：
| 场景 | 并发 | 时长 | 目的 |
|---|---|---|---|
| verify | 1 | 10s | 连通性 / 功能验证 |
| mixed_10 | 10 | 60s | 标准压测（日常量级） |
| mixed_20 | 20 | 60s | 加压（峰值量级） |
| mixed_50 | 50 | 60s | 极限（容量上限） |
| longrun_20 | 20 | 300s | 长稳（稳定性 / 泄漏） |
关键实现：参数全部经 -Jxxx 命令行传入，用 Shell 脚本 run_batch.sh 按「场景名|并发|时长」批量顺序执行；场景间 sleep 让连接池冷却，避免相互干扰。
主要结论
- 吞吐随并发先线性放大、后逼近上限：1→10→20 并发吞吐约 680→6,600→12,200 次/秒；20→50 并发仅 +6%，已接近当前配置吞吐上限。
- 高并发下瓶颈是连接池而非数据库：JMX 中
poolMax=20写死，50 线程共享最多 20 条连接 → 多余请求排队，表现为时延走高而吞吐不涨（50 并发平均时延由 ~1.6ms 升至 ~3.7ms）。 - 写路径是延迟主构成：读 SELECT 约 0.4ms 级、写 UPDATE 约 2.5–5ms；高并发时写延迟劣化最明显（锁竞争 + 连接排队）。
- 长稳无忧：20 并发 5 分钟全程吞吐稳定、无性能劣化与泄漏迹象。
- 功能层面全部通过：唯一异常为 20 次瞬时响应超时（耗时略超 SLA 且集中在同一瞬间），非数据库功能性错误，判定为偶发抖动。
踩过的坑 & 解决
| 坑 | 现象 | 解决 |
|---|---|---|
| 连接池固定写死 | 高并发吞吐封顶、只在排队 | poolMax 与线程数对齐，用 -JpoolMax=$threads 参数化 |
| 断言口径不清 | 瞬时超时难以定性 | 明确「响应码 200 但超 SLA」也算失败，并把瞬时超时与系统性故障区分开 |
| 环境残留干扰 | 前序场景影响后序 | 场景间 sleep 5s 冷却连接池 |
| 漏监控 DB 侧 | 吞吐瓶颈难定位在 CPU/IO/锁 | 补 sar/vmstat/慢查询，把吞吐时延与资源关联 |
| 5 分钟长稳偏短 | 慢泄漏可能漏检 | 生产预演延长到 30min–1h，并盯连接池/内存曲线 |
| 缺端到端覆盖 | 只验证了 DB 直连 | 上线前补应用层全链路压测（覆盖连接池/SQL 映射层） |
复用价值（可提炼为通用方法论的点）
- 连接池是国产库压测的第一瓶颈候选：线程数 > 连接池上限时，压测结果反映的是连接排队而不是数据库上限——先让
poolMax ≥ threads再谈容量。 - SLA 通过率要量化：给出总样本数 + 失败数 + 失败率（本例 5,932,401 样本 / 20 失败 / 0.0034%），比「通过/失败」定性结论更有汇报价值。
- 用「分层加压 + 长稳」两个维度闭环验证：短时并发（低压→高压找容量点）+ 长时稳定（中压验稳定与泄漏）缺一不可。
- 读写分体看：混合场景只给总吞吐会掩盖「读快写慢」——分项 SELECT/UPDATE 指标才能定位优化对象。
脱敏自检清单（已过）
- 无客户名 / 项目真名
- 无内网 IP / 域名 / 端口（原文含内网 IP，入 Wiki 前已省略）
- 业务量级已模糊化（仅保留测试指标）
- 无未公开工期 / 人员
关联
- 来源：Kingbase迁移后压测结果报告（
A10-输出/Kingbase迁移后压测方案/） - 上游方法论：PostgreSQL到国产库数据迁移方法论 · 金仓数据库（KingbaseES）数据迁移手册-PostgreSQL到金仓
- 选型前提：国产数据库选型测评方法论
- 相关：KingbaseES集群技术栈总览 · 信创国产化替代