基准测试工具

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS PostgreSQL,高可用系列 2核4GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: 基准测试工具可以用来对数据库或者操作系统调优后的性能进行对比。MySQL数据库本身提供了一些比较优秀的工具,这里介绍另外两款更优秀、更常用的工具:sysbench和mysql-tpcc。 sysbench sysbench是一个模块化的、跨平台的、多线程基准测试工具,主要用于测试各种不同系统参数下的数据库负载情况。

基准测试工具可以用来对数据库或者操作系统调优后的性能进行对比。MySQL数据库本身提供了一些比较优秀的工具,这里介绍另外两款更优秀、更常用的工具:sysbenchmysql-tpcc

sysbench

sysbench是一个模块化的、跨平台的、多线程基准测试工具,主要用于测试各种不同系统参数下的数据库负载情况。

它主要包括以下几种测试方式:

  1. CPU性能。
  2. 磁盘IO性能。
  3. 调度程序性能。
  4. 内存分配及传输速度。
  5. POSIX线程性能。
  6. 数据库OLTP基准测试。

sysbench的数据库OLTP测试支持MySQL、PostgreSQL和Oracle。目前sysbench主要用于Linux操作系统,开源社区已经将sysbench移植到Windows,并支持对Microsoft SQL Server数据库的测试。

sysbench的官网地址是:http://sysbench.sourceforge.net,可以从上述地址下载最新版本的sysbench工具,然后编译和安装。此外,有些Linux操作系统发行版本(如RED HAT),可能本身已经提供了sysbench的安装包,直接安装即可。

对于InnoDB存储引擎的数据库应用来说,我们可能更关心的是磁盘OLTP的性能,因此主要测试fileio和oltp这两个项目。

对于磁盘的测试,sysbench提供了以下的测试选项:

sysbench --test=fileio help

各个参数的含义如下所示:

--file-num:生成测试文件的数量,默认为128。

--file-block-size:测试期间文件块的大小,如果你想磁盘针对InnoDB存储引擎进行测试,可以将其设置为16 384,即InnoDB存储引擎页的大小。默认为16 384。

--file-total-size:每个文件的大小,默认为2GB。

--file-test-mode:文件测试模式,包含seqwr(顺序写)、seqrewr(顺序读写)、seqrd(顺序读)、rndrd(随机读)、rndwr(随机写)和rndrw(随机读写)。

--file-io-mode:文件操作的模式,同步还是异步,或者选择MMAP(map映射)模式。默认为同步。

--file-extra-flags:打开文件时的选项,这是与API相关的参数。

--file-fsync-freq:执行fsync函数的频率。fsync主要是同步磁盘文件,因为可能有系统和磁盘缓冲的关系。

--file-fsync-all:每执行完一次写操作,就执行一次fsync。默认为off。

--file-fsync-end:在测试结束时执行fsync。默认为on。

--file-fsync-mode:文件同步函数的选择,同样是和API相关的参数,由于多个操作系统对于fdatasync支持的不同,因此不建议使用fdatasync。默认为fsync。

--file-rw-ratio:测试时的读写比例,默认时读写2:1。

sysbench的fileio测试需要经过preparerunclean三个阶段

  1. prepare是准备阶段,生产我们需要的测试文件
  2. run是实际测试阶段
  3. cleanup是清理测试产生的文件

如我们进行16个文件、总大小2GB的fileio测试:

sysbench --test=fileio --file -num=16 --file -total -size=2G prepare

接着在相应的目录下就会产生16个文件了,因为总大小是2GB,所以每个文件的大小应该是128MB:

接着就可以基于这些文件进行测试了,下面是在16个线程下的随机读取性能:

sysbench --test=fileio --file -total -size=2G --file -test -mode=rndrd --max -time=180 --max -requests=100000000 --num -threads=16 --init -rng=on --file -num=16 --file -extra -flags=direct --file -fsync -freq=0 --file -block -size=16384 run

上述测试的最大随机读取请求是100 000 000次,如果在180秒内不能完成,测试即结束。

测试结束后可以看到如下的测试结果:

sysbench --test=fileio --file -total -size=2G --file -test -mode=rndrd --max -time=180 --max -requests=100000000 --num -threads=16 --init -rng=on --file -num=16 --file -extra -flags=direct --file -fsync -freq=0 --file -block -size=16384 run

可以看到随机读取的性能为53.81MB/sec,随机读的IOPS为3443.85。测试的硬盘是固态硬盘,因此随机读取的性能较为强劲。此外还可以看到每次请求的一些具体数据,如最大值、最小值、平均值等。

测试结束后,记得要执行clean,以确保测试所产生的文件都已删除:

sysbench --test=fileio --file -num=16 --file -total -size=2G cleanup

可能你需要测试随机读、随机写、随机读写、顺序写、顺序读等所有这些模式,并且还可能需要测试不同的线程和不同文件块下磁盘的性能表现,这时你可能需要类似如下的脚本来帮你自动完成这些测试:

#!/bin/sh
set-u
set-x
set-e
for size in 8G 64G;do
for mode in seqrd seqrw rndrd rndwr rndrw;do
for blksize in 4096 16384do
sysbench--test=fileio--file-num=64--file-total-size=$size prepare
for threads in 1 4 8 16 32do
echo"======testing$blksize in$threads threads"
echo PARAMS$size$mode$threads$blksize>sysbench-size-$size-mode-$mode-threads-$threads-blksz-$blksize
for i in 1 2 3do
sysbench--test=fileio--file-total-size=$size--file-test-mode=$mode\
--max-time=180--max-requests=100000000--num-threads=$threads--init-rng=on\
--file-num=64--file-extra-flags=direct--file-fsync-freq=0--file-block-size=$blksize run\
|tee-a sysbench-size-$size-mode-$mode-threads-$threads-blksz-$blksize 2>&1
done
done
sysbench--test=fileio--file-total-size=$size cleanup
done
done
done

对于mysql的OLTP测试,和fileio一样,同样需要经历prepare、run和cleanup的阶段。prepare阶段会根据选项产生一张指定行数的表,默认表在sbtest架构下,表名为sbtest(sysbench默认生成表的存储引擎为InnoDB),如创建一张有8000万条记录的表:

sysbench --test=oltp --oltp -table -size=80000000 --db -driver=mysql --mysql-socket=/tmp/mysql.sock --mysql-user=root prepare

接着就可以根据产生的表进行oltp的测试:

sysbench --test=oltp --oltp -table -size=80000000 --oltp -read -only=off --init -rng=on --num -threads=16 --max -requests=0 --oltp -dist -type=uniform --max -time=3600 --mysql -user=root --mysql -socket=/tmp/mysql.sock --db -driver=mysql run>res

我们将测试结果放入了文件res中。

结果中罗列出了测试时很多操作的详细信息,transactions代表了测试结果的评判标准,即TPS,上述测试的结果是119.9tps。你可以对数据库进行调优后再运行sysbench的oltp测试,看看tps是否有所提高。注意,sysbench的测试只是基准测试,并不代表实际企业环境下的性能指标。

mysql-tpcc

TPC(Transaction Processing Performance Council,事务处理性能协会)是一个评价大型数据库系统软硬件性能的非盈利组织。TPC-C是TPC协会制定的,用来测试典型的复杂OLTP(在线事务处理)系统的性能。目前,在学术界和业界,普遍采用TPC-C来评价OLTP应用的性能。

TPC-C用3NF(第三范式)虚拟实现了一家仓库销售供应商公司,拥有一批分布在不同地方的仓库和地区分公司。当公司业务扩大时,将建立新的仓库和地区分公司。通常每个仓库供货覆盖10家地区分公司,每个地区分公司服务3000名客户。该公司共有100 000种商品,分别储存在各个仓库中。该系统包含了库存管理、销售、分发产品、付款、订单查询等一系列操作,一共包含了9个基本关系,基本关系图如下图所示。

TPC-C的性能度量单位是tpmC,tpm是transaction per minute的缩写,C代表TPC的C基准测试。该值越大,代表事务处理的性能越高。

tpcc-mysql是开源的TPC-C测试工具,该测试工具完全遵守TPC-C的标准。其官方网站为:https://code.launchpad.net/~percona-dev/perconatools/tpcc-mysql。之前tpcc-mysql主要工作在Linux操作系统上,我已经将其移植到了Windows平台,可以在http://code.google.com/p/david-mysql-tools/downloads/list下载到windows版本的tpcc-mysql。

tpcc-mysql由以下两个工具组成:

tpcc_load:根据仓库数量,生成9张表中的数据。

tpcc_start:根据不同选项进行tpcc测试。

tpcc_load命令的使用方法如下所示:tpcc_load

usage:

tpcc_load[server][DB][user][pass][warehouse]

OR

tpcc_load[server][DB][user][pass][warehouse][part][min_wh][max_wh]*[part]:1=ITEMS 2=WAREHOUSE 3=CUSTOMER 4=ORDERS

上述各参数解析如下:

server:导入的MySQL服务器IP。

DB:导入的数据库。

user:mysql的用户名。

pass:mysql的密码。

warehouse:要生产的仓库数量。

如果用tpcc_load工具创建100个仓库的数据库tpcc,可以这样:

mysql tpcc<create_table.sql

mysql tpcc<add_fkey_idx.sql

tpcc_load 127.0.0.1 tpcc2 root xxxxxx 100

tpcc_start命令的使用方法如下所示:tpcc_start

usage:tpcc_start[server][DB][user][pass][warehouse][connection][rampup][measure]

相关参数的作用如下:

connection:测试时的线程数量。

rampup:热身时间,单位为秒,这段时间的操作不计入统计信息。

measure:测试时间,单位为秒。

如我们使用tpcc_start进行16个线程的测试,热身时间为10分钟、测试时间为20分钟,如下代码所示。

tpcc_start 127.0.0.1 tpcc root xxxxxx 100 16 600 1200

在测试的时候,你也许会在终端上看到如下输出:

RAMP-UP TIME.(1 sec.)

MEASURING START.

10,624(0):0.4,624(0):0.2,62(0):0.2,63(0):0.6,62(0):0.8

20,990(0):0.2,988(0):0.2,98(0):0.2,99(0):0.4,98(0):0.6

30,1435(0):0.2,1436(0):0.2,144(0):0.2,143(0):0.2,144(0):0.4

这些信息是每10秒tpcc测试的结果数据,tpcc测试一共测试5个模块,分别是New Order、Payment、Order-Status、Delivery、Stock-Level。

第一个值即为New Order,这也是TPCC测试结果的一个重要考量标准New Order Per 10 Second(每十秒订单处理能力),可以将测试时所有的数据组成一张折线图或散点图,观察InnoDB存储引擎每10秒的性能表现。而tpcc_load最后结束时产生的tpmC,也是通过New Order Per 10 Second来进行的:首先求出New Order Per 10 Second的平均值,然后乘以6,得到的就是最终的tpmC。

 

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
MySQL数据库入门学习
本课程通过最流行的开源数据库MySQL带你了解数据库的世界。   相关的阿里云产品:云数据库RDS MySQL 版 阿里云关系型数据库RDS(Relational Database Service)是一种稳定可靠、可弹性伸缩的在线数据库服务,提供容灾、备份、恢复、迁移等方面的全套解决方案,彻底解决数据库运维的烦恼。 了解产品详情: https://www.aliyun.com/product/rds/mysql 
目录
相关文章
|
21天前
|
机器学习/深度学习 人工智能 测试技术
EdgeMark:嵌入式人工智能工具的自动化与基准测试系统——论文阅读
EdgeMark是一个面向嵌入式AI的自动化部署与基准测试系统,支持TensorFlow Lite Micro、Edge Impulse等主流工具,通过模块化架构实现模型生成、优化、转换与部署全流程自动化,并提供跨平台性能对比,助力开发者在资源受限设备上高效选择与部署AI模型。
199 9
EdgeMark:嵌入式人工智能工具的自动化与基准测试系统——论文阅读
|
28天前
|
Java 测试技术 API
自动化测试工具集成及实践
自动化测试用例的覆盖度及关键点最佳实践、自动化测试工具、集成方法、自动化脚本编写等(兼容多语言(Java、Python、Go、C++、C#等)、多框架(Spring、React、Vue等))
73 6
|
2月前
|
前端开发 Java jenkins
Jmeter压力测试工具全面教程和使用技巧。
JMeter是一个能够模拟高并发请求以检查应用程序各方面性能的工具,包括但不限于前端页面、后端服务及数据库系统。熟练使用JMeter不仅能够帮助发现性能瓶颈,还能在软件开发早期就预测系统在面对真实用户压力时的表现,确保软件质量和用户体验。在上述介绍的基础上,建议读者结合官方文档和社区最佳实践,持续深入学习和应用。
553 10
|
2月前
|
监控 Java 数据挖掘
利用Jmeter工具进行HTTP接口的性能测试操作
基础上述步骤反复迭代调整直至满足预期目标达成满意水平结束本轮压力评估周期进入常态监控阶段持续关注系统运转状态及时发现处理新出现问题保障服务稳定高效运作
322 0
|
3月前
|
敏捷开发 运维 数据可视化
DevOps看板工具中的协作功能:如何打破开发、测试与运维之间的沟通壁垒
在DevOps实践中,看板工具通过可视化任务管理和自动化流程,提升开发与运维团队的协作效率。它支持敏捷开发、持续交付,助力团队高效应对需求变化,实现跨职能协作与流程优化。
|
4月前
|
数据可视化 测试技术 Go
Go 语言测试与调试:`go test` 工具用法
`go test` 是 Go 语言内置的测试工具,支持单元测试、基准测试、示例测试等功能。本文详解其常用参数、调试技巧及性能测试命令,并提供实际项目中的应用示例与最佳实践。
|
4月前
|
Java 测试技术 容器
Jmeter工具使用:HTTP接口性能测试实战
希望这篇文章能够帮助你初步理解如何使用JMeter进行HTTP接口性能测试,有兴趣的话,你可以研究更多关于JMeter的内容。记住,只有理解并掌握了这些工具,你才能充分利用它们发挥其应有的价值。+
779 23
|
3月前
|
人工智能 数据可视化 测试技术
UAT测试排程工具深度解析:让验收测试不再失控,项目稳稳上线
在系统交付节奏加快的背景下,“测试节奏混乱”已成为项目延期的主因之一。UAT测试排程工具应运而生,帮助团队结构化拆解任务、清晰分配责任、实时掌控进度,打通需求、测试、开发三方协作闭环,提升测试效率与质量。本文还盘点了2025年热门UAT工具,助力团队选型落地,告别靠表格和群聊推进测试的低效方式,实现有节奏、有章法的测试管理。
|
4月前
|
弹性计算 JavaScript Ubuntu
WebSocket协议相关的测试命令工具使用简介
本文介绍了针对WebSocket的测试工具wscat和websocat的基本使用方法,以及通过curl命令测试HTTP/HTTPS协议的方式。对于WebSocket,直接使用curl测试较为复杂,推荐使用wscat或websocat。文中详细说明了这两种工具的安装步骤、常用参数及连接示例,例如在ECS上开启8080端口监听并进行消息收发测试。此外,还提供了curl命令的手动设置头部信息以模拟WebSocket握手的示例,但指出curl仅能作为客户端测试工具,无法模拟服务器。
831 4
|
10月前
|
Java 测试技术 数据安全/隐私保护
软件测试中的自动化策略与工具应用
在软件开发的快速迭代中,自动化测试以其高效、稳定的特点成为了质量保证的重要手段。本文将深入探讨自动化测试的核心概念、常见工具的应用,以及如何设计有效的自动化测试策略,旨在为读者提供一套完整的自动化测试解决方案,帮助团队提升测试效率和软件质量。

热门文章

最新文章