盡管隨著業界發展，處理器速度、內存大小以及I/O執行速度在快速增長，但I/O操作的吞吐量和響應時間仍然比內存訪問操作要慢得多。此外，由于很多
工作負載都涉及到I/O操作，磁盤I/O很容易成為系統的瓶頸。因此，磁盤讀寫性能往往是
性能測試中一向需要考量的環節。
本次測試目標
本次磁盤性能測試對宿主機和各個規格云主機的磁盤性能做出加壓。并重點關注云主機之間的互相影響，以及云主機與宿主機之間的影響。
根據這個思路，設計以下四個測試點。
測試點一：單獨測試各規格云主機的性能。一來將測試結果作為基準數據，二來通過對比IOPS與磁盤空間的比例關系來驗證磁盤QoS是否起作用。
測試點二：設計宿主機磁盤使用率成梯度負載，測試一臺云主機、多臺云主機混合場景下的云主機磁盤性能變化。用于得出宿主機磁盤負載對其上云主機磁盤性能的影響。
測試點三：宿主機空閑，云主機之間的互相影響。一臺云主機磁盤設計成梯度負載，測試另一臺云主機的磁盤變化情況。
測試點四：多臺云主機組合加壓，使得宿主機的磁盤使用率呈現梯度，在這種場景下，測試宿主機磁盤性能。用于得出云主機磁盤壓力對宿主機磁盤性能的影響。
設計
測試用例時，應當時刻記住測試目的。先想好要得到什么樣的結果，要得到什么樣的對比，然后再有針對性的設計用例。做對比時，要保證只有一個參數再變動，如此才能得出這個參數對結果的影響。
工具選取與調研
考慮到
用例設計中的各種場景以及想要掌握的資源指標，最后選取了Fio作為本次測試的工具。Fio是一個用來對硬件I/O進行
壓力測試和驗證的工具。支持13種不同的I/O引擎，包括：sync, mmap, libaio, posixaio, SG v3, splice, null, network, syslet, guasi, solarisaio 等。
在Fio中，可以設置的選項有：
讀寫方式：隨機讀、隨機寫、順序讀、順序寫、隨機讀寫、順序讀寫。
文件大小：Fio進行I/O操作時使用的文件大小。
運行時間：一次測試執行的時間，在該時間段內，Fio將不斷執行I/O操作。
混合場景讀寫比例：如果指定為讀寫操作（讀與寫操作都有），那么可以指定讀與寫占的時間比例。
線程數：指定多線程同時執行相同的測試任務。
Fio輸出結果中含有iops、延遲時間、磁盤占用率等指標數據。
在本次測試中，通過指定Fio的rate_iops參數，即限定云主機讀寫的負載，來達到用例中設計的組合場景。
在使用Fio時，可以通過設定job文件，可以實現多條訪問規則的順序執行，進而縮減命令行中的選項長度。
一個job文件可以控制產生特定數目的線程和文件。典型的job文件有global段，一個或多少job段。
運行時，fio從文件讀這些參數，做處理，并根據這些參數描述，啟動這些仿真線程/進程。
運行job的方式： fio job_file
job文件采用經典的ini文件，[]中的值表示一項job的名稱。
監控指標的確定
磁盤I/O的性能經常基于吞吐率和延遲來評估。磁盤驅動器對大數據量順序傳輸的處理常常優于小數據量隨機傳輸操作。對于磁盤的監控指標，主要集中在以下三個方面：
測試工具Fio統計的指標：iops，bps（傳輸速度），延遲時間。
系統cpu相關的指標：%usr，%sys，%iowait，中斷次數，上下文切換次數。特別關注cpu0的使用情況。
系統磁盤I/O相關的指標：tps，await，svctm，%util。
上述各項指標含義如下：
IOPS：每秒鐘處理的磁盤IO次數，由fio工具統計得出。
BPS：每秒鐘處理的數據量大小，由fio工具統計得出。
延遲時間：
%usr：在用戶級別運行所使用的CPU的百分比，由mpstat命令統計得出。
%sys：在系統級別(kernel)運行所使用CPU的百分比，由mpstat命令統計得出。
%iowait：因IO導致的進程等待，由mpstat命令統計得出。
中斷：CPU中斷次數，由vmstat命令統計得出。
上下文切換：CPU的控制權由運行任務轉移到另外一個就緒任務時所發生的事件次數，由vmstat命令統計得出。
tps:每秒從物理磁盤I/O的次數，由iostat命令統計得出。
await：從設備流出的平均I/O請求時間,包括請求在隊列和服務時的時間，由iostat命令統計得出。
svctm：平均I/O請求的服務時間，由iostat命令統計得出。
磁盤util%：磁盤利用率，由iostat命令統計得出。
測試過程
一、測試腳本的準備與驗證
1.編寫運行在云主機上的測試腳本
該腳本主要用于觸發Fio進行測試，并制定log文件的存放路徑。
2.將測試腳本及監控腳本拷貝至云主機
為了讓測試過程盡可能自動化，在宿主機上將必要的文件分發到特定云主機上執行。需要的文件有測試腳本及負責監控的腳本。
3.ssh遠程執行云主機上腳本
宿主機上通過ssh命令使云主機上測試腳本運作，并觸發監控腳本對資源使用情況進行記錄。
4.收集結果數據拷貝回宿主機
云主機上測試結束后，統一將各個輪次結果拷貝回宿主機歸檔，便于后續集中處理。
二、指標監控的實現
使用Perfease進行資源監控。 工具介紹鏈接：http://doc.hz.netease.com/pages/viewpage.action?pageId=16782036
三、測試結果的收集與整理
使用monitor.sh會將測試過程中所有的指標數據統計并保存到文件中。而為了保證監控數據的有效性，監控的時效往往略小于真實測試時間。此外專門編寫了腳本來計算各指標的平均值，但將各輪測試的結果挑選出來放進報告中頗為費時。
而在整理數據的過程中，可能會遇到一些問題，例如同一用例跑兩輪，兩輪結果誤差較大。當誤差超過5%時，基本可以認定其中有一組數據無效。需要再跑一輪測試進行驗證。
還有可能會發現，結果數據是準確的，但與對應場景預期的結果不符。這種情況可能是腳本參數設置不對，也有可能暴露了其他問題。需要對這種情況需要找開發了解相關背景信息，進而定位原因。
測試結論與總結
針對四個測試點的測試目的分別對測試結果進行提煉總結，結果與測試前的預期相符：
通過測試不同規格的云主機磁盤性能，各云主機iops比例與云主機磁盤空間比例相近，可以驗證磁盤QoS起了作用。
隨著宿主機磁盤負載增加，云主機iops快速下降；await與svctm差值增大，表明IO在請求隊列中的時間增加；%iowait增大，cpu等待io時間變長。
宿主機磁盤空閑時，單臺云主機磁盤負載增加，對其他云主機的磁盤性能影響很小。多臺云主機負載增加時，其他云主機IO等待時間變長。
隨著云主機磁盤負載增加，宿主機iops減少，await與svctm差值增大，說明IO請求在隊列中時間增加。
預測試的重要性
預測試是指在正式測試之前對基本功能的一個基本驗證。在這個過程中進行一些探索和驗證，小規模的模擬正式測試來提前暴露一些問題，最終降低測試成本與風險。
這幾個月下來的工作給我的體會是，性能測試過程似乎具備這樣的特點：
測試工具需要設置多項參數來實現業務規模、場景負載等條件，各項指標間可能需要捆綁設置。即測試條件較復雜。
執行一個輪次下來往往時間很長，且大多數測試工具在執行完成后才會出具結果報告。即測試時間較漫長。
測試環境要保證前后一致。測試進程盡量獨占整個系統，避免測試外的因素影響最終結果。
鑒于以上幾點，如果因為測試腳本或測試環境的原因影響了結果，則會造成很大的時間損失。而引入預測試的目的，就是幫助我們提前檢驗測試腳本和測試環境，估量實際測試時間并發現需要人工介入的時刻。
此外，由于預測試幫助我們快速地領略了一遍測試過程的“生命周期”，正式測試時會更加得心應手。
及時發現問題
即便使用預測試來提前收集測試信息，但如何能夠確保測試腳本和測試環境不出一點問題呢？很多時候我們發現不了錯誤是因為我們根本不知道自己犯了錯誤。
“實踐是檢驗真理的唯一方法”，確保能發現的問題已經解決后，只好提心吊膽地開始正式測試了。
測試執行過程雖然漫長，但不能掉以輕心，時刻關注新鮮出爐的結果數據。若結果表現與預期不符，要及早定位問題：是系統誤差，還是測試工具設置不對，還是數據收集時統計錯了目標？
越早發現問題，越能節省成本。
向測試自動化靠攏
由于測試需要關注宿主機與云主機兩方面的資源情況，監控數據需要分別收集。且測試用例設計了各種負載梯度，造成測試腳本和Fio的job文件偏多，需要對應分發到各個云主機上。這些都是繁瑣但不可缺少的環節，為了防止人工操作帶來的失誤，在這些機械的操作盡可能地編寫腳本令其自動實現。
自動化除了可以用來分發測試腳本、收集測試數據，還可以對新分配的云主機進行初始化，例如安裝必要的工具包、更新軟件源等等操作。
總而言之，自動化是一項提高效率，避免機械繁瑣操作的好思路、好方法。磨刀不誤砍柴工，花一點時間編寫自動化工作的腳本，能為后續工作帶來極大便利。