/tags/%E6%80%A7%E8%83%BD/ Recent content in 性能 on Hugo -- gohugo.io en Tue, 04 Aug 2026 07:18:15 +0800 /posts/oceanbase-tidb-stress-test/ Tue, 04 Aug 2026 07:18:15 +0800 /posts/oceanbase-tidb-stress-test/ 背景 这轮压测的对象是一套用 WebFlux / R2DBC 写的响应式服务。数据库先从 OceanBase（下称 OB）换到 TiDB Cloud，又换回来，最后跑了一轮同拓扑 A/B 对照。被测接口每笔请求展开约 27 条串行 SQL（其中约 9 条写），外加 16.6 次 Redis 往返。 先把口径摆出来，后面所有数字都在这套配置下： 项 这次的取值 被测服务 WebFlux + R2DBC 响应式服务，跑在 K8s 的 perf 命名空间 OB 规格 3 × 8c32g observer + OBProxy 专属集群 6c12g × 2（最后一轮升到 32c70g × 3） TiDB TiDB Cloud 按 RU 计费的那一版，4 台 tidb-server 网关，store 从 5 台加到 8 台 发压端 k6，先是笔记本走公网，之后改成集群内 Pod 直连 Service 阶梯 起始 200/s，步长 100/s，每档跑满 3 分钟，只取稳态窗口 负载打散 10 万玩家，最后一轮 100 万 应用连接池 R2DBC，max-size 一路从 10 调到 400、50、200、250 两边计费方式不同，对比方案要跟着改。OB 买的是固定规格，按 AWS 上的 vCPU 和内存付费，压不压成本都一样；我测的这版 TiDB 按 RU 计费，用多少算多少。直接比吞吐没有意义，所以顺序是先跑 OB，在固定规格下压出一个延迟可接受的 RPS 当基准，再看 TiDB 在相近延迟、相近 RPS 下要花多少。后面反推「每笔业务消耗多少 RU」就是为这一步。