近日工作中遇到了一个磁盘压测时性能上不去的问题，经排查，发现原因有以下几个方面：
1 测试参数的选择
2 业务逻辑未关闭
本文就将通过对磁盘性能测试指标及参数的介绍，来理解以上两个原因为什么会对测试结果有影响。
首先来介绍一下磁盘性能的测试指标。
最常用的磁盘性能评价指标有两个：IOPS和吞吐量（throughput）。IOPS是Input/Output Per Second的缩写，它表示单位时间内系统能处理的I/O请求数量，即每秒钟系统能处理的读写次数。
吞吐量衡量单位时间内系统能处理的数据的体量，即每秒钟磁盘上能读写出的数据量的大小，通常以kB/s或MB/s为单位。
两个指标相互独立，又相互关联，在不同业务场景下，侧重关注的指标也有所不同。
对于文件尺寸小，随机读写比较多的场合，比如在线交易处理系统，我们倾向于更关注IOPS，因为我们更在乎的是每秒钟能处理多少条交易。
而对于文件尺寸较大，顺序读写比较多的场合，比如视频播放服务，数据吞吐量将会成为我们主要的考量指标。
举个例子来帮助我们更好的理解这两个指标。磁盘IO就相当于我们有货物（数据）需要从A处（系统）与B处（磁盘）之间往返。货物（数据量）有多有少，因此运货车也有大有小。B处有装卸工人负责将货物卸载到仓库的指定位置，或者从仓库指定位置提取货物装载到货车上。
每次货车运输一趟货物就相当于处理一个IO请求，工人装卸货物就相当于磁盘对IO的读写处理。在工人数量和工人装卸货物速度（磁盘数据处理速度）保持一定的情况下，装卸大车上货物的时间一定会比小车上的时间长，装卸一大车货物的时间，可能已经够小车运输若干趟货物（IOPS高）。但是小车由于多次往返，其花在路上的时间要比大车多，同时每次装卸货物工人需要寻找正确的位置存取货物（磁盘寻址时间），比起大车的一次寻址，小车运货就也浪费了更多时间。因此在相同时间内，采用大车运输的货物总量是比小车要多的（吞吐量高）。
这也是为什么我们在做磁盘性能测试的时候，通常一次只关注一个指标，追求IOPS，就用小车运输少量货物，多次往返。追求吞吐量，就用大车运送大量货物，节省路上及寻址所花费的时间。
下面再说一下磁盘测试的影响因素。
实际测量中，IOPS会受到很多因素的影响，比如：
1 数据块大小
相当于我们前面说的大车和小车运货的情况
2 顺序和随机
顺序就是我们的货物都按顺序安排在仓库的一处，随机则意味着货物随机的分配在仓库的不同地点，可以想见，货物地点存放比较随机的情况下，存取货物一定是更费时间的。
3 队列深度
如果我们每次只发一辆货车在AB之间往返，那么当货车在A处处理货物或者在AB之间的路上跑的时候，B处的工人就处于闲置的状态，压力测试时，我们绝对不希望这种情况发生，我们需要工人（磁盘）一直工作，从而得出磁盘的最高性能。想实现这一点，我们可以通过一次发多辆车来解决，保持始终有车辆在等待处理的队伍里，这样装卸工人就一直有工作可做了。
队列深度就是等待处理的队伍里的货车以及正在被装卸的货车的总数量。
4 线程数
测试时，增加线程数也可以增加并发度，从而使装卸工人一直处于有工作可做的状态。
5 读写比例
读操作相当于我们将货从B中的仓库取出来，运到A处就结束了。而写操作意味着货物在A处经过一番处理之后还要再运回B处并存储在仓库中。因此不同的读写比例也会造成测试结果的不同。
正是由于这些不同影响因素的存在，我们在对磁盘进行性能测试时，需要仔细选择测试参数，否则将无法测出磁盘的最优性能。同时应将测试参数和方法定性定量，否则测试结果将失去比较的价值。
以 云盘参数和性能测试方法：
https://help.aliyun.com/document_detail/25382.html
一文中介绍的测试IOPS的方法为例，我们来看一下linux常用测试工具fio的参数如何体现以上影响因素。
测试随机写IOPS：
fio -direct=1 -iodepth=128 -rw=randwrite -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/dev/[device] -name=Rand_Write_Testing
测试随机读IOPS：
fio -direct=1 -iodepth=128 -rw=randread -ioengine=libaio -bs=4k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/dev/[device] -name=Rand_Read_Testing
测试写吞吐量：
fio -direct=1 -iodepth=64 -rw=write -ioengine=libaio -bs=1024k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/dev/[device] -name=Write_PPS_Testing
测试读吞吐量：
fio -direct=1 -iodepth=64 -rw=read -ioengine=libaio -bs=1024k -size=1G -numjobs=1 -runtime=1000 -group_reporting -filename=/dev/[device] -name=Read_PPS_Testing
其中：
iodepth：队列深度。异步引擎下起作用。
rw: 读写模式，可选模式有顺序写write、顺序读read、随机写randwrite、随机读randread、混合随机读写randrw。
ioengine: 负载引擎。libaio引擎用于发起异步IO请求。
bs: IO块大小。
numjobs 测试线程数。
对比四个测试方法的参数我们可以看到，测试IOPS时我们采用小数据块（bs=4k），测试吞吐量时则用大数据块（bs=1024k）。这和我们前面说到的大货车小货车的选择原理是一致的。
队列深度对IOPS的影响要大于对吞吐量的影响，因为我们测试IOPS时选择的iodepth更大。但iodepth也不是越大越好，因为当装卸工人数量、装卸货物速度、仓库寻址时间一定之后，单位时间内所能处理的最大货物量也就确定了，即磁盘的能力确定了。一味增加队列深度，增加的只能是货物在队列里的等待时间，即平均IO响应时间。
我们可以通过查看装卸工人的忙碌程度来决定是否要增加队列深度。如果磁盘的busy%为100%，那就表示所有工人都在一刻不停歇的装卸货物了，已经不再有提升的空间，此时再增加队列深度或是数据量大小对测试结果都将是徒劳。反之，则表示磁盘压力尚未到极限，得出的数据不能代表磁盘性能最高水平。
磁盘压测时如果有其他业务逻辑在运行会怎样呢？这种情况就相当于有一部分货车装运的是业务逻辑的数据，而这些货车也会占用我们的队列和装卸工人，测试引擎将无法百分之百的使用全部队列和装卸工人，那么我们的测试结果将不能体现整个磁盘的能力。尤其是当业务逻辑所涉及的IO是同步（synchronous）请求的时候，对测试结果的影响将更大，因为同步IO就相当于前面说到的一次只让一辆车在路上跑，只有等它跑完才会发下一辆车。因此在压力测试的时候，我们需要将业务逻辑关闭的。
