要点
pgbench（官方 PostgreSQL 工具，工作负载接近 TPC-B）和 sysbench-tpcc（TPC-C 工作负载更能代表真实的事务负载）都直接针对 Aurabase 项目的标准 Postgres 16 连接字符串运行 — 无需绕过专有 API。本教程展示了实际订单，以及 GST 数据可以合法证明的范围。
pgbench 更简单，sysbench-tpcc 更真实
pgbench 随 PostgreSQL 本身一起分发：如果您已经拥有 Postgres 客户端工具，则无需在客户端上单独安装。其默认工作负载再现了接近历史 TPC-B 基准的负载 — 简单、启动快速、对于第一个信号很有用。
sysbench 是一个更通用的基准测试工具，带有一个 sysbench-tpcc 插件，可复制 TPC-C 工作负载 — 代表真实 OLTP 应用程序（订单、付款、库存）的事务组合，比通用 pgbench 工作负载更接近 Aurabase 后端在生产中处理的情况。
检索连接字符串并创建专用测试库
1
从 Aurabase 仪表板检索连接字符串
项目的数据库部分，标准 postgresql://user:password@host:5432/dbname格式。
2
创建一个单独的测试基地，而不是您的生产基地
psql "$AURABASE_CONN" -c "创建数据库 bench_test;"
pgbench 和 sysbench-tpcc 创建、填充和修改表。始终使用专用基地，切勿使用服务实际流量的方案。
初始化并启动首次运行
1
初始化数据集
pgbench -i -s 10 "postgresql://user:pass@host:5432/bench_test" # -s 10 = 比例因子（pgbench_accounts 中的 10 × 100,000 行）
2
运行 60 秒，10 个竞争客户端
pgbench -c 10 -j 2 -T 60 -P 5 "postgresql://user:pass@host:5432/bench_test" # -c = 并发客户端 · -j = 线程 · -T = 持续时间（以秒为单位） · -P = 每 5 秒报告一次
3
读取结果
pgbench 在运行结束时显示 tps （每秒事务数），有或没有连接时间。注意比例因子、客户端数量和每次运行的持续时间——如果没有这三个参数，数字本身就没有任何意义。
更具代表性的事务工作负载
1
安装 sysbench 和 tpcc 插件
git clone https://github.com/Percona-Lab/sysbench-tpcc.git # 按照存储库的 README 编译插件
2
准备 TPC-C 数据集
./tpcc.lua --pgsql-host=主机 --pgsql-user=用户 --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 准备
3
开始运行
./tpcc.lua --pgsql-host=主机 --pgsql-user=用户 --pgsql-password=pass \ --pgsql-db=bench_test --warehouses=10 --time=300 --threads=16 --report-interval=10 运行
Percona 于 2026 年 5 月发布了专门针对 PostgreSQL 的 sysbench-tpcc 调优指南 — 对于在运行代表性运行之前调优 shared_buffers 和 work_mem 非常有用。
商品及服务税 (GST) 数字本身并不能证明什么
tps 取决于比例因子、并发客户端数量、底层硬件以及运行时处于活动状态的 Postgres 设置。即使在同一数据库上，使用不同参数获得的两个时间数据也不具有可比性。
为了将您的结果作为可重现的参考，请系统地记录：Postgres 版本、比例因子、客户端/线程数、运行持续时间和有效的 postgresql.conf 配置。请参阅我们完整的 基准测试方法，了解我们在发布数据之前应用的协议。
在重新启动运行之前调整 Postgres
基准测试运行通常会在任何调整之前揭示出瓶颈——连接饱和、自动清理滞后、索引缺失。我们的 Postgres 生产中的调整清单 以及关于 max_connections 大小调整 的文章涵盖了重新启动运行之前要检查的设置。