MySQL 学习篇（三）3.2 基准测试准备前的步骤和脚本（上）

目录

前言

基准测试的步骤

Get_Test_info脚本

analyze脚本

基准测试中容易忽略的问题

总结

---

 

• 前言

之前我们已经知道了什么是基准测试、基准测试的目标，本章讲述基准测试步骤！

                                                                               

• 基准测试的步骤

1. 计划和设计基准测试【要尽可能的简单，要明确我们所基准测试对象，多次测试取得平均统计结果，反映出系统的真实的性能】

• 对整个系统还是某一个组件
• 使用什么样的数据（我们希望基准测试能够反映出系统的实际情况，那么最好就可以使用生产环境的全备份实际数据和实际运行的SQL，来完成基本测试，比较复杂和耗时】
• 准备基准测试及数据收集脚本【对于测试数据的准备，提前获取真实数据的数据库的备份，以及真实环境中运行SQL的记录，对于SQL的执行的记录，就可以通过慢查日志全部记录下来的方式来获得，而如果我们的测试没有必要使用真实数据的话，测试工具都可以提供数据的生成以及相关sql脚本生成的功能，但是对于测试执行过程中系统状态的收集的脚本就需要你自己来编写了】

• Get_Test_info脚本

[root@localhost ~]# cd script/
[root@localhost script]# ll
总用量 12216
-rw-r--r--. 1 root root 12478174 12月 11 15:43 1.sql
-rw-r--r--. 1 root root      344 12月 11 15:43 analyze.sh
-rw-r--r--. 1 root root      801 12月 11 15:43 Get_Test_info.sh
-rw-r--r--. 1 root root    12611 12月 11 15:43 mysql-variables
-rw-r--r--. 1 root root      548 12月 11 15:43 split_test.sh
[root@localhost script]# vi Get_Test_info.sh 

      1 #!/bin/bash
      2 INTERVAL=5 
      3 PREFIX=/home/imooc/benchmarks/$INTERVAL-sec-status
      4 RUNFILE=/home/imooc/benchmarks/running
      5 echo "1" > $RUNFILE
      6 MYSQL=/usr/local/mysql/bin/mysql
      7 $MYSQL -e "show global variables" >> mysql-variables
      8 while test -e $RUNFILE; do
      9         file=$(date +%F_%I)
     10         sleep=$(date +%s.%N | awk '{print 5 - ($1 % 5)}')
     11         sleep $sleep
     12         ts="$(date +"TS %s.%N %F %T")"
     13         loadavg="$(uptime)"
     14         echo "$ts $loadavg" >> $PREFIX-${file}-status
     15         $MYSQL -e "show global status" >> $PREFIX-${file}-status &
     16         echo "$ts $loadavg" >> $PREFIX-${file}-innodbstatus
     17         $MYSQL -e "show engine innodb status" >> $PREFIX-${file}-innodbstatus &
     18         echo "$ts $loadavg" >> $PREFIX-${file}-processlist
     19         $MYSQL -e "show full processlist\G" >> $PREFIX-${file}-processlist &
     20         echo $ts
     21 done
     22 echo Exiting because $RUNFILE does not exists
~                                                                                                                                                                                              
~                                                                                                                                                                                              
~                                                                                                                                                                                              
~                                                                                                                                                                                              
~                                                                                                                                                                                              
~                                                                                                                                                                                              
~                                                                                                                                                                                              
~                                                                                                                                                                                              
~                                                                                                                                                                                              
~                                                                                                                                                                                              
~                                                                                                                                                                                              
~                                                                                                                                                                                              
~                                                                                                                                                                                              
:set nu

# 解释说明：
# Line 1-2：脚本的运行间隔（每隔多长时间，收集一次状态信息）
# Line 3：状态信息记住到什么目录
# Line 4：指定了一个运行标识（存在则脚本的运行/停止则删除脚本信息）
# Line 5：运行标识文件
# Line 6：MySQL命令所在的位置
# Line 7：记录下当前测试Mysql的测试信息
# Line 8：循环（前提标识文件存在的情况下）
# Line 9-11：脚本运行时间、文件名、运行间隔
# Line 13：收集系统负载情况并且记录到文件中
# Line 15：收集MySQL全局状态信息并且记录到文件中
# Line 17: InnoDB状态信息
# Line 19: MySQL线程情况

• analyze脚本

#!/bin/bash
awk '
   BEGIN {
     printf "#ts date time load QPS";
     fmt=" %.2f";
   }
   /^TS/ {
   ts = substr($2,1,index($2,".")-1);
   load = NF -2;
   diff = ts - prev_ts;
   printf "\n%s %s %s %s",ts,$3,$4,substr($load,1,length($load)-1);
   prev_ts=ts;
   }
   /Queries/{
   printf fmt,($2-Queries)/diff;
   Queries=$2
   }
   ' "$@"

• 基准测试中容易忽略的问题

使用生产环境的真实数据进行测试时，我们只使用了真实数据的一个子集，而不是全部的生产环境数据，前面在讲解准备基准测试数据的时候，如果我们希望使用生产环境的数据来进行测试，那就最好是使用数据库的一个完全的备份，而不是人为的从全部数据中选择出一小部分数据来进行测试；

比如说我们的真实环境中，数据库的有几百个G，而我们在测试时为了方便，人为的选择了几个G的一个子集，是不能反映出系统的真实情况的，而且我们人为的选择的数据也不能完全显出，生产的环境中数据的真实分布的情况，这样得出的结果呢是不准确的。

比如我们的WEB应用通常是存在大量的用户并发的使用场景，所以在对WEB应用的数据库来进行测试，我们就一定要考虑到这种并发的情况，许多的连接线程来对Mysql性能来进行测试；

通常情况下，多线程的并发的数据库性能和单线程访问的数据库性能的表现完全的不同的。

有的应用在单线程的时候可能会很好，但是一旦存在了并发访问的情况，就会出现大量的阻塞和死锁，这些问题是在单线程测试中无法发现的。so我们必须要根据，应用的实际情况来进行我们的测试的设计，而对于多用户访问的场景，一定要使用多线程的并发测试才能够达到我所想要的目的。

分布式应用的表现和单服务器的是完全的不同的，比如我们的生产环境中，数据库部署只能使用这种主从同步，并且读写分离架构。

在进行系统测试我们就也要使用相同的架构来进行测试，因为一方面来说，通常情况下读写分离的中间层会有一定的性能损耗，如果我们不考虑中间层存在性能损耗，不准的。

如果我们在基准测试中反复的使用同SQL查询，在某种程度上来说，这个查询的可能完全会在缓存中命中，所以就无法体现出生产环境的真实的安全性能。

• 总结

 

https://blog.youkuaiyun.com/Sicily_winner/article/details/87857054