关于基准测试_架构设计

基准测试

WHY ：基准测试是唯一方便有效的可以观察系统在不同压力下的行为，评估系统的容量的方法（在新系统正式上线到生产环境之前，进行基准测试是个好习惯。切勿相信提供商的言辞）
基准测试并不是基于真实压力的测试，其压力通常较为单调简单。
- 除了数据量，数据和分布不同外，基准测试在实际情况下通常会要求快速完成，压测实施者往往会施以实际中远远不能达到的且单调请求的压力，虽然有益于测量系统最大性能容量，但往往会使系统或者压测软件崩溃，得不到真正符合实际的数值。
- 例如：当压测发现新系统可以支持原系统40倍的TPS时，不能简单的就认为新系统可以支持40倍的业务增长。因为系统是个复合的系统，除了单个业务的TPS还要考虑该业务与其他业务或者系统交互之间的交互，甚至网络和磁盘的因素都要考虑到其中。
- 结论：我们只能进行大概的测试，得出系统的大致余量。基准测试要尽量简单直接，结果之间要容易相互比较，成本低且易于执行。可以使用控制变量法。
基准测试的策略
- 集成式测试：针对整个系统的整体测试，能发现各部分之间缓存带来的影响，结果更真实，但是难建立。
- 单组件测试：单独测试MySQL。需要比较不同的schema或查询的性能 / 针对应用中某个具体问题进行测试 / 为避免漫长的基准测试通过一个短期的单组件基准测试，做快速的周期循环，检测某些调整后的效果
测试指标
- 吞吐量：单位时间事务处理数，指标为TPS（每秒事务数）
- 响应时间或延迟：任务所需的整体时间。通常为平均响应时间，最小或最大响应时间。但最大响应时间往往被百分比响应时间代替。例如，若95%的响应时间都是5毫秒，则表示任务在95%的时间段内都可以在5毫秒之内完成。
- 并发性：Web服务器的并发性是指在任意时间有多少同时发生的并发请求，其高并发一般会导致数据库的高并发。但一个Web站点“同时有5W个用户”访问，却可能只有10-15个并发请求到MySQL数据库，故并发性基准测试需要关注的是正在工作中的并发操作，或者同时工作中的线程或者连接数。当并发性增加时，需要关注并测量吞吐量是否随之下降，响应时间变长。
- 可扩展性：给系统增加一倍的工作，在理想情况下就能获得两倍的结果，即吞吐量增加一倍。或者说给系统增加一倍的资源就能获得两倍的吞吐量。通常无法做到理想的线性扩展。
基准测试方法
- 常见错误：使用真实数据子集而非全集/错误的数据分布/不真实的分布参数/多用户的场景只测试单用户/在单台服务器上测试分布式应用/模拟的用户行为不真实/短时间内反复执行同一个查询/没有检查错误日志/忽略系统预热/使用默认服务器配置/测试时间太短
- 设计和规划基准测试：提出问题并明确目标→决定采用标准的基准测试还是设计专用的测试→针对数据运行查询，可在不同级别记录查询→详细写下测试规划（包括准备测试数据，系统配置的步骤，设计预热方案，测量并分析测试结果）
- 基准测试应运行足够长的时间：当对机器加压足够长的时间后，系统用来应对突发情况的余量会被消耗殆尽，系统的短期高峰也就无法维持原来的高性能，因此应当让测试一直运行到确认系统已经稳定运行之后
- 获取系统性能和状态：尽可能多地收集被测试系统的信息，最好建立一个目录。
```
#!/bin/sh
  
INTERVAL=5 #每个5s收集一次
PREFIX=$INTERVAL-sec-status
RUNFILE=/root/running
mysql -e 'show global variables'>>mysql-variables
while  test -e $RUNFILE; do
        file=$(date +%F_%H) # 文件名包含了测试开始日期和小时
        sleep=$(date +%s.%N |awk "{print $INTERVAL -($1 % $INTERVAL)}")
        sleep $sleep
        ts="$(date +"TS %s.%N %F %T")" 
        loadavg="$(uptime)"
        echo "$ts $loadavg">> $PREFIX-${file}-status
        mysql -e "show global status" >> $PREFIX-${file}-status &
        echo "$ts $loadavg">> $PREFIX-${file}-innodbstatus
        mysql -e "show engine innodb statusG" >> $PREFIX-${file}-innodbstatus &
        echo "$ts $loadavg">> $PREFIX-${file}-processlist
        mysql -e "show full processlistG" >>$PREFIX-${file}-processlist &
        echo $ts
done
echo Exiting because $RUNFILE not exist
```
- 获得准确的测试结果
  - 审查基本问题
  - 确认测试结果是否有可重复性。每次重新测试之前都要确保系统的状态是一致的，甚至每次测试之前都重启系统，并确保每次预热的时间足够长。如果预热测试用的是随机查询，则测试结果可能就不是可重复的。如果测试的过程中会修改数据或者DDL，那么每次测试之前，需要利用快照还原数据。
  - 可以利用控制变量法，每次测试中，修改的参数应该尽量少。一般情况下都是通过迭代逐步地修改基准测试的参数。
  - 基于默认配置的测试没有什么意义，因为默认配置是基于消耗很少内存的极小应用。
  - 如果在测试中出现异常结果，不要轻易当作垃圾结果直接丢弃，应当认真研究并找到产生这种结果的原因。如果对测试结果不了解，就不要轻易公布。
- 运行测试并分析结果
- 绘图的重要性
测试工具
- 常用集成式测试工具：ab / http_load / JMeter
- 常用单组件测试工具：mysqlslap（包含在MySQL的安装包中）/ sql-bench（包含在MySQL的安装包中（5.6及以前））/ TPCC / percona‘s TPCC（针对订单交易型）/ sysbench（全能的多线程系统压测工具，可以配合Lua脚本进行多样化的系统软硬件测试）

关于基准测试

架构设计相关栏目本月热门文章