近日工作中遇到了一個磁盤壓測時性能上不去的問題，經排查，發現原因有以下幾個方面：
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處并存儲在倉庫中。是以不同的讀寫比例也會造成測試結果的不同。
正是由于這些不同影響因素的存在，我們在對磁盤進行性能測試時，需要仔細選擇測試參數，否則将無法測出磁盤的最優性能。同時應将測試參數和方法定性定量，否則測試結果将失去比較的價值。
以 雲盤參數和性能測試方法：
<a href="https://help.aliyun.com/document_detail/25382.html">https://help.aliyun.com/document_detail/25382.html</a>
一文中介紹的測試IOPS的方法為例，我們來看一下linux常用測試工具fio的參數如何展現以上影響因素。
其中：
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就相當于前面說到的一次隻讓一輛車在路上跑，隻有等它跑完才會發下一輛車。是以在壓力測試的時候，我們需要将業務邏輯關閉的。