新手和专家都必须要掌握的基准测试,你了解多少

发表于:2020-9-25 09:24

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:中门对狙    来源:简书

分享:
  基准测试MySQL新手和专家都必须要掌握地一项基本技能。基准测试是针对系统设计的一种压力测试。通常的目标是为了掌握系统的行为。
  基准测试的策略
  基准测试有两种主要的策略:一是针对整个系统的整体测试,另外是单独测试MySQL。这两种测试也被称为集成式以及单组件式基准测试。针对整个系统做集成式测试而不是单独测试MySQL的原因有以下几点:
  测试整个应用系统,包括web服务器、应用代码、网络和数据库是非常有用的,因为用户关注的并不是MySQL本身的性能,而是应用整体的性能。
  MySQL并非总是应用的瓶颈,通过整体的测试可以揭示这一点。
  只有对应用做整体测试,才能发现各部分之间的缓存带来的影响。
  整体应用的集成式测试更能揭示应用的真实表现,而单独组件的测试很难做到这一点。
  有时候不需要了解整个应用的情况,而只需要关注MySQL的性能,至少在项目初期可以 这样做。基于以下情况,可以选择只测试MySQL
  需要比较不同的schema或查询的性能
  针对应用中某个具体的测试
  为了避免漫长的基准测试,可以通过一个短期的基准测试,做快速的"周期循环",来检测某些调整后的效果
  测试何种指标
  考虑以下指标,看看如何满足测试的需求:
  吞吐量
  吞吐量指的是单位时间内的事务处理数。这一直是经典的数据库应用测试指标。这类基准测试主要针对在线事务处理OLTP的吞吐量,非常适用于多用户的交互式应用。常见的测试单位是每秒事务数,有些也采用每分钟事务数。
  响应时间或者延迟
  这个指标用于测试任务所需的整体时间。根据具体的应用,测试的时间单位可能是微秒、毫秒、秒或者分钟。根据不同的时间单位可以计算出平均响应时间、最小响应时间、最大响应时间和所占百分比。最大响应时间意义不大,因为测试时间越长,最大响应时间也可能越大。而且其结果通常不可重复,每次测试都可能获得不同的最大响应时间。因此,通常可以使用百分比响应时间来代替最大响应时间。例如,如果95%的响应时间都是5毫秒,则表示任务在95%的时间段内都可以在5毫秒内完成。
  并发性
  并发性是一个非常重要又经常被误解和误用的指标。例如,它经常被表示成多少用户在同一时间浏览一个web站点,经常使用的指标是有多少个会话。然而,HTTP协议是无状态的,大多数用户只是简单地读取浏览器上显式地信息,这并不等于web服务器的并发性。而且web服务器的并发性也不等同于数据库的并发性,而仅仅只表示会话存储机制可以处理多少数据的能力。web服务器的并发性更准确的度量指标,应该是任意时间内有多少同时发生的并发请求。
  在应用的不同缓解都可以测量相应的并发性。web服务器的高并发,一般也会导致数据库的高并发,但服务器采用的语言和工具集对此都会有影响。注意不要将创建数据库连接和并发性搞混淆。一个设计良好的应用,同时可以打开成百上千个MySQL数据库服务器连接,但可能同时只有少数连接在执行查询。所以说一个web站点"同时有50000个用户"访问,却可能只有10-15个并发请求到MySQL数据库
  换句话说,并发性基准测试需要关注的是正在工作中的并发操作,或者是同时工作中的线程数或者连接数。当并发增加,需要测量吞吐量是否下降,响应时间是否变长,如果是这样,应用可能就无法处理峰值压力。
  并发性测试通常不是为了测试应用能达到的并发度,而是为了测试应用在不同并发下的性能。可以通过sysbench指定32、64或者128个线程的测试,然后在测试期间记录MySQL数据库的Threads_running状态值。
  可扩展性
  在系统的业务压力可能发生变化的情况下,测试可扩展性就非常必要了。可扩展性指的是,给系统增加一倍的工作,在理想情况下就能获得两倍的结果(即吞吐量增加一倍)。或者说,给系统增加一倍的资源就可以获得两倍的吞吐量。同时性能也必须在可以接收的范围内。大多数系统是无法做到如此理想的线性扩展的。随着压力的变化,吞吐量和性能都可能越来越差。
  可扩展性指标对于容量规范非常有用,它可以提供其他测试无法提供的信息,来帮助发现应用的瓶颈。
  归根结底,应该测试那些对用户来说最重要的指标。因此应该尽可能地去收集一些需求,比如,什么样地响应时间是可以接受的,期待多少的并发性,等等。然后基于这些需求来设计基准测试,避免目光短浅地只关注部分指标,而忽略其他指标。
  sysbench
  sysbench可以执行多种类型的基准测试,它不仅设计用来测试数据库的性能,也可以测试运行数据库的服务器的性能。
  sysbench的基本语法
sysbench [options]... [testname] [command]
  命令
  command是sysbench要执行的命令,包括prepare,run和cleanup,顾名思义,prepare是为测试预先准备数据,run是执行正式的测试,cleanup是在测试完成后对数据库进行清理。
  测试名
  testname指定了要进行的测试,在老版本的sysbench中,可以通过–test参数指定测试的脚本;而在新版本中,–test参数已经声明为废弃,可以不使用–test,或者直接指定脚本。
  例如,如下两种方法效果是一样的:
sysbench --test=/usr/share/sysbbench/tests/include/oltp_legacy/oltp.luasysbench /usr/share/sysbbench/tests/include/oltp_legacy/oltp.lua
  yum安装的sysbench的测试脚本默认在/usr/share/sysbench下面及其下面的文件夹
  选项
  sysbench的参数有很多,其中常见的包括
--mysql-host:MySQL服务器主机名,默认localhost;如果在本机上使用localhost报错,提示无法连接MySQL服务器,改成本机的IP地址应该就可以了。
--mysql-port:MySQL服务器端口,默认3306
--mysql-user:用户名
--mysql-password:密码
--mysql-db=test    在test这个数据库进行测试,默认sbtest
--mysql-socket=/data/mysql/datanode1/node1.soc 指定socket
  MySQL执行参数
--oltp-test-mode:执行模式,包括simple、nontrx和complex,默认是complex。simple模式下只测试简单的查询;nontrx不仅测试查询,还测试插入更新等,但是不使用事务;complex模式下测试最全面,会测试增删改查,而且会使用事务。可以根据自己的需要选择测试模式。
--oltp-tables-count:测试的表数量,根据实际情况选择
--oltp-table-size:测试的表的大小,根据实际情况选择
--oltp-read-olny=off  读写混合
--threads:客户端的并发连接数
--time:测试执行的时间,单位是秒,该值不要太短,可以选择120
--report-interval:生成报告的时间间隔,单位是秒,如10
--max-requests=0   设置最大请求,0为不限制,想多少请求都可以,在限定的时间内
--percentile=99   去签名99%的数据进行分析
  sysbench的CPU基准测试
  服务器的CPU配置如下
[root@cy ~]# cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 79
model name  : Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
stepping    : 1
microcode   : 0x1
cpu MHz     : 2394.456
cache size  : 35840 KB
physical id : 0
siblings    : 1
core id     : 0
cpu cores   : 1
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 13
wp      : yes
  在这台服务器上运行如下的测试
[root@cy ~]# sysbench --test=cpu --cpu-max-prime=20000 run

Threads started!

CPU speed:
    events per second:   295.01

General statistics:
    total time:                          10.0008s
    total number of events:              2951

Latency (ms):
         min:                                    3.27
         avg:                                    3.39
         max:                                   11.17
         95th percentile:                        3.55
         sum:                                 9994.76

Threads fairness:
    events (avg/stddev):           2951.0000/0.00
    execution time (avg/stddev):   9.9948/0.00
  第二台服务器配置
[root@iZniul0kz47rtgZ ~]# cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 85
model name  : Intel(R) Xeon(R) Platinum 8269CY CPU @ 2.50GHz
stepping    : 7
microcode   : 0x1
cpu MHz     : 2500.002
cache size  : 36608 KB
physical id : 0
siblings    : 1
core id     : 0
cpu cores   : 1
apicid      : 0
initial apicid  : 0
fpu     : yes
fpu_exception   : yes
cpuid level : 22
wp      : yes
  执行测试
[root@iZniul0kz47rtgZ ~]# sysbench --test=cpu --cpu-max-prime=20000 run

CPU speed:
    events per second:   343.75

General statistics:
    total time:                          10.0024s
    total number of events:              3439

Latency (ms):
         min:                                    2.78
         avg:                                    2.91
         max:                                   23.83
         95th percentile:                        2.97
         sum:                                 9999.19

Threads fairness:
    events (avg/stddev):           3439.0000/0.00
    execution time (avg/stddev):   9.9992/0.00
  可以看到CPU运行速度第二台服务器比第一台要快
  sysbench的文件IO测试
  文件IO基准测试可以测试系统在不同IO负载下的性能。这对于比较不同的磁盘驱动器、RAID卡、不同的RAID模式,都很有帮助。可以根据测试结果来调整IO子系统。文件IO基准测试模拟了很多InnoDB的IO特性
  测试第一步是准备阶段,生成测试用到的数据文件,生成的数据文件至少比内存大。如果文件中的数据能完全放入内存中,则操作系统缓存大部分的数据,导致测试结果无法体现IO密集型的工作负载
  首先创建一个数据集
[root@cy ~]# sysbench --test=fileio --file-total-size=30G prepare
  这个命令会在当前工作目录下创建测试文件,后续的运行阶段将通过读写这些文件进行测试
  针对不同的IO类型有不同的测试选项
  seqwr:顺序写入
  seqrewr:顺序重写
  seqrd:顺序读取
  rndrd:随机读取
  rndwr:随机写入
  rdnrw:混合随机读/写
  下面的命令运行文件IO混合随机读/写基准测试
[root@cy ~]# sysbench --test=fileio --file-total-size=30G --file-test-mode=rndrw --max-time=300 --max-requests=0 run
  得到的结果
File operations:
    reads/s:                      902.00
    writes/s:                     601.34
    fsyncs/s:                     1924.64

Throughput:
    read, MiB/s:                  14.09
    written, MiB/s:               9.40

General statistics:
    total time:                          300.0067s
    total number of events:              1028295

Latency (ms):
         min:                                    0.00
         avg:                                    0.29
         max:                                 1949.82
         95th percentile:                        0.73
         sum:                               298892.25

Threads fairness:
    events (avg/stddev):           1028295.0000/0.00
    execution time (avg/stddev):   298.8922/0.00
  测试完成后,运行清除操作,删除第一步生成的测试文件
[root@cy ~]# sysbench --test=fileio --file-total-size=30G cleanup
  sysbench MySQL基准测试
  生成3张表,每个表插入100000条数据
[root@cy ~]# sysbench  /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --table_size=100000 --threads=20 --oltp-tables-count=3  --mysql-db=test --mysql-user=root --mysql-host=106.13.177.139 --mysql-password=123.com prepare
  数据测试
sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --oltp-table-size=100000 --oltp-tables-count=3 --mysql-db=test --mysql-user=root --mysql-host=106.13.177.139 --mysql-password=123.com --time=60 --max-requests=0 --threads=8 --report-interval=10 run
  --threads=8     //线程数为8
  --time=60       //测试时间为60s
  --report-interval=10  //报告打印周期为10s,每10s打印一次
  --oltp-read-only=off  //非只读操作测试
  测试结果
[ 10s ] thds: 8 tps: 92.57 qps: 1896.81 (r/w/o: 1332.89/119.86/444.06) lat (ms,95%): 253.35 err/s: 1.90 reconn/s: 0.00
[ 20s ] thds: 8 tps: 23.90 qps: 477.92 (r/w/o: 334.41/38.90/104.60) lat (ms,95%): 893.56 err/s: 0.00 reconn/s: 0.00
[ 30s ] thds: 8 tps: 24.00 qps: 478.80 (r/w/o: 335.00/42.60/101.20) lat (ms,95%): 1032.01 err/s: 0.00 reconn/s: 0.00
[ 40s ] thds: 8 tps: 26.60 qps: 531.20 (r/w/o: 371.60/53.20/106.40) lat (ms,95%): 1304.21 err/s: 0.00 reconn/s: 0.00
[ 50s ] thds: 8 tps: 21.30 qps: 427.00 (r/w/o: 298.90/41.70/86.40) lat (ms,95%): 1235.62 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 8 tps: 18.50 qps: 368.40 (r/w/o: 257.70/40.90/69.80) lat (ms,95%): 1453.01 err/s: 0.00 reconn/s: 0.00
SQL statistics:
    queries performed:
        read:                            29344
        write:                           3390
        other:                           9148
        total:                           41882
    transactions:                        2077   (32.16 per sec.)
    queries:                             41882  (648.45 per sec.)
    ignored errors:                      19     (0.29 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          64.5861s
    total number of events:              2077

Latency (ms):
         min:                                   10.06
         avg:                                  235.33
         max:                                 7159.95
         95th percentile:                     1013.60
         sum:                               488775.18

Threads fairness:
    events (avg/stddev):           259.6250/35.75
    execution time (avg/stddev):   61.0969/1.45
  queries:查询总数及qps
  transactions:事务总数及tps
  Latency-95th percentile:前95%的请求的最大响应时间,本例中是1013毫秒,这个延迟非常大,是因为我用的MySQL服务器性能很差;在正式环境中这个数值是绝对不能接受的。
  清除数据
sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua --oltp-tables-count=3 --oltp-table-size=100000 --mysql-user=root --mysql-host=106.13.177.139 --mysql-password=123.com --mysql-db=test cleanup
  sysbench的其他特性
  内存
  测试内存的连续读写性能
  线程
  测试线程调度器的性能。对于高负载情况下测试线程调度器的行为非常有用。
  互斥锁
  测试互斥锁的性能,方式是模拟所有线程在同一时刻并发运行,并都短暂请求互斥锁(互斥锁mutex是一种数据结构,用来对某些资源进行排他性访问控制,防止因并发访问导致问题)。
  顺序写
  测试顺序写的性能。这对于测试系统的实际性能瓶颈很重要。可以用来测试RAID控制器的高速缓存的性能状况。

      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理

《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号