最近，越來越多的第三方獨立機構推出了云服務測試報告，這個現象讓我有些喜憂參半。喜的是數據的大爆炸，企業的轉型意識，互聯網的發展已經讓云計算市場迅速進入了紅海階段，人們對云的需求與依賴性越來越高。憂的是也有打著云服務獨立測試的旗號讓一些并不真實的數據展現在受眾面前的事情發生。

七牛進入云服務領域四年了，我們從云存儲做切入口，到目前積累了大約幾十萬用戶。在這里，將“如何更好地測試云存儲服務性能”分享出來，希望能讓更多的在選擇云和往云上遷移的企業獲益。

首先，普及一個基礎知識：我們認為，在互聯網的世界里有三類不同的數據：1. 結構化數據，也就是關系型數據。2. 日志類型的數據，即記錄用戶行為軌跡的數據。3. 非結構化數據，也就是我們經常使用和產生的文件類數據，如圖片、音視頻數據等。就目前來說，大家所接觸到的公有云存儲一般是針對第三類也就是非結構化數據的存儲，除了存儲本身，也會提供數據加速(CDN)以及數據處理等服務，七牛就是這樣。 這里面，每一個子服務都會對應相關的獨立測試，而本篇文章更多的是探討如何做好存儲本身的性能測試。

了解了基本概念，在測試前，我們先理解下典型的數據使用環境下的三個主要階段。

***階段指數據從客戶端到存儲的服務端(服務入口)，即上行階段。上行的表現一方面是由用戶的網絡質量決定的，同時也與云存儲服務商上行節點的優化策略有關。這時，最重要的是做好整體的網絡優化，以及在軟件層面解決由于網絡不穩而帶來的上行問題。例如，斷點續上傳，模式是分片并發上傳，是能很好地解決網絡不穩的方法。因此，我們在為“美拍”服務的時候，對方是非常典型的短視頻UGC場景，就充分用到了斷點續上傳的功能。此外，增加存儲節點和反向代理節點也可以優化劣質網絡環境下的用戶上行問題。上行這個展開了，也是一個獨立測試。

第二階段就主要依賴云存儲服務本身的性能表現。例如，在數據達到存儲入口之后，需要多久才能落地到磁盤;在取一個數據時，數據要多久才能從磁盤到達存儲的出口等。這個階段的測試也是下文五個關鍵點中所主要描述的。

第三個階段指數據的下行階段。數據一般是由普通用戶來使用的，而從存儲邊緣到達客戶端的數據下行表現是由CDN決定的，因此這個階段的性能評測是典型的CDN性能評測，很多文章中均有詳細描述，這邊就不做具體描述了。

那么如何針對云存儲本身的性能表現做有效評測呢?我們分五個關鍵點來說。

***個關鍵點：

保障測試機的性能。目前絕大多數云存儲服務的性能都不弱，因此，在測試時，保障充足的帶寬是非常非常必要的，同時，CPU等資源也要確保充足。此外，如果是通過上傳小文件來進行測試的話，則盡量從內存生成小文件，而不是從磁盤生成，以免由于磁盤IOPS不夠，而影響測試的準確性。而如果上傳的是大文件，那么***不要受到測試機帶寬的限制。同理，如果是下載一個小文件，***不要落磁盤，直接將其扔掉就好了，以避免磁盤成為性能瓶頸。

第二個關鍵點：

將測試機與云存儲服務的距離控制在合理的范圍內。機器離云存儲的距離是非常關鍵的，因為如果兩者之間的距離太大的話，跳數、丟包率、延遲等都會極大影響測試的效果。一般測試，通常會選擇在同一個供應商同機房提供的虛擬機上來做云存儲性能測試，這樣不僅測試起來會比較方便，而且能確保測試結果準確有效。

這里面要說到七牛的一個特殊情況，七牛目前對外是不提供虛擬機的，虛擬機的使用是要實名申請審批的，因此第三方獨立測試機構在測試七牛時，也希望能夠更好地確認這一點。

第三個關鍵點：

根據存儲數據的大小，關注相應的測試指標。通常都會選擇Get(下載)和Put(上傳)來測試云存儲本身的服務性能。這里面會考察響應時間與TPS(平均每秒處理的事務數)。

那么，我們推薦以實際用戶為基準來考慮測試數據的大小。對于圖片數據來說，可以關注50KB和2MB兩個級別，主要因為一般手機拍照的圖片大小在1MB到2MB這個級別，這對圖片上行和下載原圖都比較關鍵。而50KB是比較常見的縮略圖的大小，也就是在網頁上展示的絕大部分圖片都是這個大小。當然網站上還會有logo、圖標等圖片，可能會更小，但這類圖片基本上都是重復的，這樣CDN的緩存效率比較高，一般體驗都不會差。而容易造成用戶體驗差的，反而是那些每次大小都不一樣、每個頁面都不會重復的圖片，它們才是評估的關鍵。而如果是做短視頻產品，如常見的10秒的短視頻，文件大小通常是1-2MB，應該關注這個級別的上行和下行。如果是更長的視頻，也應該關注相對應的測試大小。

第四個關鍵點：

測試數據的頭尾都是不能要的。在測試時，一般要選取中間的數據，因為最開始的時候，由于程序啟動或者其他干擾原因會導致性能不太穩定，一般性能會差一些的。同時，尾部的數據通常也需要去掉，比如使用多線程測試時，各個線程結束的時間不一致，也會導致測試尾部的數據偏差較大。

第五個關鍵點：

推薦對云存儲服務做一些高并發的測試，這樣可以考驗云存儲供應商的真實能力，即在處理高并發情況下的成功率。但做高并發測試時，用比較傳統的Java、Python等語言不太合適，因為在線程模型下它們的并發能力受系統能支撐的線程數限制，高并發的寫法又比較復雜。而用Go、Erlang、Scala，Node.js等語言則會方便不少。

由于國內還沒有特別權威的第三方做獨立對比測試的機構，所以***是自己來做測試，按照上面的方式，也很簡單。

此外，選擇云存儲，除了上面談到的云存儲本身的性能，用戶也需要關注存儲的可用性以及性價比等方面。關于可用性，自己寫一個腳本，放在crontab里邊跑一段時間，收集一下數據就可以了。目前，國內有些云服務供應商為了讓用戶能實時了解服務的可用性，從而更放心地使用云服務，已推出系統健康狀態實時監控服務，例如在 status.qiniu.com上就可以看到七牛的完整可用性紀錄以及關鍵性能指標。當然，也要考察覆蓋度問題，不過覆蓋度問題一般由CDN提供支持，也有聽云這類比較易用的測試服務。

當下，AWS、Azure等海外云服務也已經落地國內，他們在國內通常也具備了以上測試條件，因此測試方式并無不同。

***想說的是，到了今天，越來越多的企業在選擇云，基礎技術對用戶而言也越來越隱形，而以用戶的需求為中心，專注云服務的質量才是廠商真正最需要做的。