基准测试工具

本文涉及的产品
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
云数据库 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。

 

相关实践学习
基于CentOS快速搭建LAMP环境
本教程介绍如何搭建LAMP环境,其中LAMP分别代表Linux、Apache、MySQL和PHP。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
17天前
|
网络协议 安全 测试技术
性能工具之emqtt-bench BenchMark 测试示例
【4月更文挑战第19天】在前面两篇文章中介绍了emqtt-bench工具和MQTT的入门压测,本文示例 emqtt_bench 对 MQTT Broker 做 Beachmark 测试,让大家对 MQTT消息中间 BenchMark 测试有个整体了解,方便平常在压测工作查阅。
107 7
性能工具之emqtt-bench BenchMark 测试示例
|
29天前
|
测试技术 C语言
网站压力测试工具Siege图文详解
网站压力测试工具Siege图文详解
29 0
|
2月前
|
测试技术 持续交付
现代软件测试中的自动化工具应用与挑战
随着信息技术的快速发展,软件行业对于质量和效率的要求日益提高,自动化测试工具在软件开发过程中扮演着至关重要的角色。本文将探讨现代软件测试中自动化工具的应用现状以及所面临的挑战,旨在帮助开发人员更好地理解并充分利用这一技术手段。
|
11天前
|
机器学习/深度学习 数据采集 人工智能
【专栏】利用AI辅助工具提高软件测试效率与准确性
【4月更文挑战第27天】本文探讨了AI在软件测试中的应用,如自动执行测试用例、识别缺陷和优化测试设计。AI辅助工具利用机器学习、自然语言处理和图像识别提高效率,但面临数据质量、模型解释性、维护更新及安全性挑战。未来,AI将更注重用户体验,提升透明度,并在保护隐私的同时,通过联邦学习等技术共享知识。AI在软件测试领域的前景广阔,但需解决现有挑战。
|
2月前
|
jenkins 测试技术 持续交付
现代软件测试中的自动化工具与挑战
随着信息技术的飞速发展,现代软件测试中的自动化工具扮演着越来越重要的角色。本文将探讨自动化工具在软件测试中的应用以及所面临的挑战,旨在帮助软件测试人员更好地理解和应对当前行业的技术趋势。
|
2天前
|
测试技术 API
探索软件测试中的自动化工具与挑战
本文探讨了软件测试领域中自动化工具的应用与挑战。通过分析目前主流的自动化测试工具,探讨了其在提高测试效率、减少人工成本、增强测试覆盖率等方面的优势。然而,自动化测试也面临着诸如脆弱性、维护成本高等挑战。最后,提出了一些应对挑战的建议,以期为软件测试领域的自动化工作提供一些启示。
10 1
|
7天前
|
机器学习/深度学习 人工智能 测试技术
提升软件测试效率与准确性的策略与工具
【5月更文挑战第2天】 在软件开发生命周期中,测试阶段是确保产品质量的关键。然而,传统的测试方法往往耗时且容易出错。本文将探讨一系列现代软件测试策略和工具,旨在提高测试效率和准确性。我们将分析自动化测试框架、持续集成(CI)、测试驱动开发(TDD)以及人工智能(AI)在测试中的应用,并讨论如何结合这些技术和方法来优化测试流程。
|
8天前
|
敏捷开发 监控 测试技术
探索自动化测试工具Selenium Grid的高效集成策略
【4月更文挑战第30天】在现代Web应用的快速迭代和持续部署中,测试自动化已成为确保产品质量的关键。Selenium Grid作为一款支持多种浏览器和操作系统的测试工具,提供了并行执行测试用例的能力,极大地提升了测试效率。本文将深入探讨如何高效地将Selenium Grid集成到现有的测试框架中,以及实施过程中的最佳实践,帮助团队最大化测试覆盖率,同时降低资源消耗。
|
8天前
|
中间件 测试技术 API
探索自动化测试工具的新边界:Selenium与Appium的集成实践
【4月更文挑战第30天】 随着移动应用和Web应用的不断融合,传统的自动化测试工具需要适应新的测试环境。本文将详细分析Selenium和Appium这两款流行的自动化测试工具的集成实践,探讨如何构建一个能够同时支持Web和移动端应用的自动化测试框架。通过对比两者的技术架构、功能特性以及在实际项目中的集成过程,我们旨在为读者提供一个清晰的指导,帮助他们在复杂的应用环境中实现高效、稳定的自动化测试流程。
|
8天前
|
机器学习/深度学习 人工智能 机器人
深入理解自动化测试:框架、工具与实践
【4月更文挑战第30天】 在现代软件开发周期中,自动化测试已成为确保产品质量和加速市场交付的关键环节。本文将探讨自动化测试的核心框架、常用工具以及实际应用的最佳实践,旨在为软件测试工程师提供深入的理解和有效的策略,以改进其自动化测试流程。我们将分析几种流行的测试自动化框架,包括Selenium、Appium和JUnit,并讨论如何根据项目需求选择适合的工具。此外,文中还将介绍持续集成(CI)环境下的自动化测试策略,以及如何通过测试结果分析和报告来优化测试过程。目标是帮助读者构建更健壮、更高效的自动化测试系统。