身在儲存行業，自然離不開儲存效能測試。對於效能測試，一般有兩種方法：
1. 使用業內比較認可的效能測試工具，比如iometer、fio、iozone等。這類工具一般是開源的，應用範圍很廣泛，使用它們的乙個好處是可以快速和其他儲存產品做橫向對比。哪怕大家是在不同時間、不同地點、不同環境測試的，但只要引數設定差不多，就可以拿來簡單對比（如果要做完整對比，必須放在同樣的環境中測試）。不足之處是它們只能按照預定義的模式機械測試，大多數情況下無法真實反應實際應用環境的io模式。
2. 直接在真實的應用環境中進行效能測試。這種方法測出來的結果，針對特定的場景，具有權威的參考性。不足之處就是搭建環境可能比較麻煩，每個應用的依賴環境都不一樣。即使是同樣的儲存裝置，在不同的應用場景，其效能差異也很大。所以這種方法能反應儲存產品在特定場景下的實際效能，但有時候並不能確定儲存產品的普遍效能。
使用同樣的儲存裝置，同樣的硬碟，當如下條件變化時，效能差異可能會很明顯。
1. 讀和寫。理論上，機械硬碟的順序讀寫效能差不多。但在不同的場景，同樣硬碟的讀寫效能是有差異的。因為寫資料的時候，快取的作用更大，所以寫的效能可能更好。但如果使用raid5，因為寫資料有寫懲罰，所以在其他條件相同時，讀的話效能更好。ssd的讀寫引數天生就不一樣，因為寫資料會引起塊擦除，所以往往讀更快，尤其是隨機讀。
2. 順序io和隨機io。對於機械硬碟，毫無疑問，順序讀寫比隨機讀寫快很多，因為順序讀寫少了很多尋道時間，其速度比隨機讀寫高出1到2個數量級。所以，傳統的儲存需要使用快取演算法（包括按扇區位址的排序以及預讀等）來減少尋道時間，提高效能。對於ssd，順序讀寫和隨機讀寫差別不是那麼大，但是順序讀寫一般來說會比隨機讀寫快。實際應用中，純隨機讀寫很少，即使在檔案系統中拷貝大檔案，也有一些相對隨機的操作，比如修改元資料，跳過一些被占用的扇區等。所以，如何模擬應用程式的隨機度，是乙個比較頭疼的問題。
3. 塊大小（block size）。如果單次io寫入的資料塊比較大，比如超過了1mb，效能顯然比較好。即使是機械硬碟純隨機寫入1mb也如此——單個資料塊往往是一次性提交給驅動的，每個塊內部的資料一般也是連續的。每秒只需要少量的io能過去，就能獲得較大的頻寬，因為頻寬＝io大小*io數，io數雖然不多，但io平均大小較大。但也有例外。如果把塊大小設定成很大（比如1gb），在系統裡面肯定會被拆分成較小的io發下去，所以效能不會有進一步改善，在應用程式不夠完善時反而會導致額外的問題（比如直接就給分配了1gb的記憶體導致記憶體有可能不足）。即使前面說的1mb的io，在很多系統中，也可能會被拆分成2個或者幾個io發下去。如果是順序讀寫，4kb的小io，在作業系統內部也可能會被合併成大的io，所以這種情況下，效能不會太差，但合併io等步驟本身需要消耗資源，所以效能也不會太好。需要注意的是，有些時候，評判效能標準不是按讀寫頻寬來看，而是按照每秒的io數（iops）來看。顯然，塊大小的設定就比較難提高iops的值了。
4. 快取的影響。當讀寫快取比較大時，效能顯然會好一些。尤其是進行隨機寫測試，在寫快取比較大時，剛開始的效能值會非常大（其實就是寫到記憶體的速度），到後來一下子降下來。因此，為了避開快取的的影響，有時候需要測試direct io。但在大多數應用場景下，快取都是需要使用的，我們得了解在快取起作用的情況下的效能，同時又要跳開剛開始測試階段的不穩定性能值，那我們可以設定相應的時間引數，不把最開始的一段時間的效能值統計進去。iometer的ramp up time就是為這個準備的。有人拿同樣的配置測試隨機讀寫，兩次測出的值大不一樣，其原因就有可能是沒有把這個原因考慮進去。即使設定了ramp up time，但其值太小，在快取還沒有寫滿的時候其時間就到了，也會統計得不準確。
5. 同步io和非同步io。同步io是發乙個io，等確認完成之後，再發下乙個io。這是乙個序列的過程。非同步io是發了乙個io，還沒有完成，就發下乙個io，io的處理過程是非同步的。顯然，非同步io的效能一般會好一些。iometer和fio等都能對它們進行測試。iometer有乙個「# of outstanding i/os」的引數，用於設定可以同時發的非同步io的個數。如果要測試出比較好的效能，一般要用非同步io。
6. 其他影響因子。太多了，無法一一枚舉。比如多執行緒、機械硬碟的外圈和內圈等。現在的機械硬碟內部結構很複雜，扇區的物理排布和硬碟的韌體有關，但一般可以簡單認為，機械硬碟的開始部分（扇區位址較小部分，或者簡單認為是外圈）比結尾部分（扇區位址較大部分，或者簡單認為是內圈）的速度要快。
因為有如此多的影響效能的因素，所以，也需要測試工具要提供眾多引數來進行設定，以便精準地測試效能的原因。但實際的應用場景可能更複雜，有可能一會兒是大塊的順序讀寫，一會兒又變得更隨機。如果我們能夠精準預估應用程式讀寫儲存的模式，理論上也可以用iometer等工具來模擬，無非是把配置寫得比較複雜而已。但有時候很難預估它的讀寫模式，所以採用實際的應用環境更具有效能參考意義。因為實際應用環境搭建麻煩，所以，有時候會自己寫一些測試工具，盡可能模擬應用場景，然後以比較簡單的模式來進行測試，可以有更高的測試效率，以便不斷改進系統。
附：
Redis儲存效能測試
在string型別中，不僅可以儲存key value中value是string型別，也可以儲存物件型別。testmodel amodel new testmodel amodel.id 1 amodel.name wongcony amodel.type 1 amodel.company nxin ...
Hive壓縮儲存效能測試
textfile格式 create table textfile id int,name string partitioned by date string row format delimited fields terminated by lines terminated by n parquet...
漫談單元測試
提起單元測試，有人覺得它沒什麼用，純屬浪費時間 有人則一頭霧水 當然也有人認為單元測試很重要，無論對專案的開發還是對程式設計師自身的提公升都大有益處。拿自身經歷來講，之前呆過的乙個小團隊也曾推過這個東西，但沒過一段時間就不了了之 作為當事人，我當時的感受就是完全不明白這東西是幹什麼的，一頭霧水，覺得...