jdbc-endpoint 的 config-connect 接缝变成一次云产品评测:用公认的
BenchBase TPC-C 实现测你运营的托管数据库的 OLTP 吞吐/goodput/延迟,并叠加性价比。
连接链路由本仓库 CI(单测 + mock)覆盖。live 步骤需要你自己的托管数据库和
BenchBase 构建——此路径下 clousight-bench 绝不代你开通数据库。不声称经审计的
tpmC;数字来自 BenchBase,unaudited。
0. 你需要
- 一个已建
benchbase库、驱动机可达的托管 PostgreSQL/MySQL 兼容实例 (阿里云 RDS/PolarDB、AWS RDS/Aurora 等)。 - 一个 BenchBase 构建(Java 17+):
benchbase放进PATH或设置BENCHBASE_HOME。 pip install clousight-bench。
1. 驱动机放哪
与所有 connect 模式评测同一条规则:驱动机放同 region(与实例同 VPC)。 公网上测 OLTP 尾延迟量的是你的运营商,不是数据库。2. 连接档案
从已提交的示例出发(examples/cloud-connect/aliyun-rds-postgres.yaml /
aws-aurora-postgres.yaml):
BENCHBASE_DB_USER / BENCHBASE_DB_PASSWORD 环境变量(BenchBase 读
配置 XML;harness 以 0600 写进 0700 工作目录,跑完即删)。
3. 先 preflight,再跑
csbench doctor 现在做真实探测:JDBC 端点的 TCP 可达性探测 + BenchBase 启动器与 Java ≥ 17 检查。地址写错、白名单没开、工具缺失或版本过旧
都会在这里带修复提示暴露——而不是变成运行中的堆栈。同样的检查也在 csbench run 的
PREFLIGHT 阶段把关。
tpc-c.throughput_req_per_sec、tpc-c.goodput_req_per_sec、
tpc-c.p99_latency_us 等——来自原样 BenchBase 的 environmental 测量。
4. 性价比
CLOUSIGHT_PRICING_DATA=feed.json csbench run … 在
extensions.pricing.price_performance[] 里加上 $ / (req/sec)——unaudited,
来自你自己的报价,永远改变不了判定。(官方 price/tpmC 需要经审计的 tpmC;
我们两者都刻意不声称。)
5. 诚实注意事项
scalefactor(warehouse 数)必须随实例规格放大——warehouse 太小量到的是锁 竞争,不是服务能力。- 装载阶段(
--create --load)在高 scalefactor 下耗时很长;把time设到让 测量窗口远大于预热效应。 - 只比较同 dbtype、同 scalefactor/terminals、同 region 局部性的数字。
