TPC-C是数据库系统经常使用的一个性能测试标准,目前开源社区里有几个可以使用的TPC-C测试工具,如BenchmarkSQL、DBT2、 tpcc-mysql等。今天这里要介绍的是另一个TPC-C测试工具: sqlbench

sqlbench 特性

sqlbench fork自DBT2,改写了整个架构,原来的DBT2把整个测试过程分成client和 driver 两个应用程序,每个terminal需要 2个线程。如果测试的warehouse较多需要占用机器大量资源。 而sqlbench对这方面做了优化,合并了这两个应用程序,同时优 化了线程的使用,使用1个线程处理多个terminal,大大减少了机器资源的使用。使一台机器可以运行更多的warehouse。另外 DBT2外部依赖较多,如对R环境的依赖,sqlbench去掉了不必要的外部依赖,目前sqlbench只依赖测试数据库的客户端库。下面 是sqlbench的部分特性:

  • 支持多种数据库,目前支持PostgreSQL、MySQL、Kingbase、ODBC
  • 支持多种协议和SQL执行方式,包括普通的SQL语句、PBE(Prepare、Bind、Execute)和存储过程1
  • 支持每种数据库的数据快速加载接口,如:PostgreSQL的 Copy,MySQL的 Load Data Local InFile,同时实现并行加载使数 据加载更快

下面将主要以测试PostgreSQL为例介绍sqlbench的安装和使用,这里我们装载20个warehouse并运行测试120秒。

sqlbench编译安装

sqlbench代码目前托管在github上,可以下载发布的版本,也可以直接使用仓库中的代码,这里以仓库中的代码为例。 下载代码解压后进入sqlbench目录先执行autreconf -if,然后执行configure:

  1. autoreconf -if
  2. ./configure --with-postgresql=yes --with-mysql=yes \
  3. --with-kingbase=<kingbase-installation-path> --with-odbc=yes
  • 这里使用 –with-postgresql指定支持postgresql测试,如果–with-postgresql指定yes,configure会在当前PATH下找 pg_config,通过pg_config配置编译的选项
  • –with-postgresql也可以接PostgreSQL的安装路径,它会根据指定的安装配置编译选项
  • –with-mysql与–with-postgresql类似,只是当指定yes时使用的是mysql_config
  • –with-kingbase只支持指定kingbase安装的路径
  • –with-odbc打开ODBC支持只能指定yes

还可以通过给configure加上–prefix选项指定安装路径。configure执行完后执行make && make install安装

创建测试表

使用psql连接到数据库通过执行源代码目录下src/scripts/create-tables.sql文件来创建测试所需的表:

  1. psql tpcc -f src/scripts/create-tables.sql
  2. # 对于MySQL使用:
  3. mysql -D tpcc <src/scripts/create-tables.sql

我们先不创建索引,这样装载数据会快一些,当装载完数据再创建索引。

装载数据

src/core/datagen用来装载数据:

  1. src/data/datagen -t postgresql --dbname=tpcc --host=127.0.0.1 -w 20 -j5
  2. # 对于MySQL类似

第一个选项使用-t来指定数据库类型(如果指定-t选项,-t必须是第一个选项,这和后面的sqlbench命令是一样的),后面的 长选项是该数据库的连接参数。对于PostgreSQL和MySQL可以指定数据库名、主机名、端口号等,具体可通过datagen –help查 看。这里如果没有指定-t选项,datagen会将数据写到文本文件,然后可通过数据库内置装载命令装载的数据库,默认文件会生 成在当前目录,可以-d改变生成文件的位置。上面还通过-w选项指定了要测试的warehouse数和-j指定了使用多少个并发装载数 据。

创建索引

数据装载完就可以创建索引了,类似于创建表,通过psql或mysql命令来执行src/scripts/create-indexes.sql脚本。创建完索 引后通过analyze命令对数据库进行analyze(MySQL对每个表运行analyze table),使用数据库在运行测试时可以生成正确的 查询计划。

运行测试

执行src/core/sqlbench命令运行测试:

  1. src/core/sqlbench -t postgresql --dbname=tpcc --host=127.0.0.1 -w 20 -l 120 -r 20 -c 5

这里:

  • -t 指定PostgreSQL数据库 –dbname和–host为数据库的连接参数,其他没指定的使用默认参数
  • -w 指定测试数据为20个warehouse
  • -l 共运行测试时间为120秒
  • -r 其中ramp up的时间为20秒
  • -c 共使用5个数据库连接

sqlbench其他的常用参数包括:

  • –no-thinktime 默认的TPC-C测试是有keying time和thinking time的,模拟真正的用户场景,可通过指定这个参数将相应 的时间设置成0,来只对CPU加压
  • –sqlapi 选择SQL执行的方式,可选:
    • simple 为普通SQL方式
    • extended 使用prepare/bind/execute方式,该方式先生成查询计划缓存起来,后面直接执行,效率更高
    • storeproc 使用存储过程,这种方式与比extended相比还节省了与数据库服务器通信的开销
  • -s与-e指定开始和结束的warehouse数,在更多warehouse时,可以使用这2个选项分配warehouse,分成多个sqlbench压测同 一个数据库
  • –altered默认情况sqlbench下根据TPC-C标准生成terminal数(每个terminal代表一个user,每个warehouse 10个terminal, 也可以使用–tpw改变),这个参数直接指定了terminal个数,被这些warehouse平均分。
  • –sleep指定每创建一个线程后sleep的时间,默认为1s
  • -o 用来指定output目录,用来存储错误日志及测试结果文件

sqlbench的其他参数是用来定制TPC-C标准的各个部分的,包括keying time、thinking time的时间,各个事务所占比率,各个 表的数据量等,默认值都是遵从TPC-C标准的。

查看测试结果

sqlbench测试过程中会将测试数据写到output目录下的mix.log中,而src/utils/post-process命令是用来处理这个文件查看测 试结果的:

  1. src/utils/post_process -l mix.log
  1. Response Time (s)
  2. Transaction % Average : 90th % Total Rollbacks %
  3. ------------ ----- ----------------- ------- ------------ -----
  4. Delivery 3.96 0.061 : 0.071 45 0 0.00
  5. New Order 46.21 0.038 : 0.052 525 5 0.95
  6. Order Status 3.61 0.007 : 0.010 41 0 0.00
  7. Payment 43.13 0.013 : 0.017 490 0 0.00
  8. Stock Level 3.08 0.011 : 0.016 35 0 0.00
  9. ------------ ----- ----------------- ------- ------------ -----
  10. 262.50 new-order transactions per minute (NOTPM)
  11. 2.0 minute duration
  12. 0 total unknown errors
  13. 20 second(s) ramping up

以上结果第1列为事务类型,第2列为该事务类型所占的比例,第3列和第4列分别为平均响应时间和90百分位数响应时间(90th percentile),TPC-C要求这2个响应时间必须小于5秒。第5列每种事务总数,第6列和第7列回滚事务数和回滚率,TPC-C要求New Order事务有一定的回滚率。最后的262.50为每分钟New Order事务的个数,这是TPC-C比较重要的一个性能指标。

post_process还可以通过-t选项输出每种事务随时间变化的每分钟执行事务数的统计数据,再配合脚本 src/utils/plot_transaction_rate可以得到对应每分钟事务数的变化曲线2

  1. src/utils/post_process -l mix.log -t transactions-rate.log
  2. src/utils/plot_transaction_rate transaction-rates.log \
  3. transactions-rate.png

下图是上面测试结果的每分钟事务数的变化曲线。 img

写在最后

目前sqlbench工具还不完善,欢迎试用这个工具,如果遇到什么问题可以在Github上提issue,如果感兴趣希望做改进也欢迎提 merge request。

Footnotes

1 目前MySQL、ODBC只支持普通的SQL方式

2 plot_transaction_rate需要系统安装gnuplot