對于那些定期執(zhí)行大量文件同步操作的云文件共享客戶來說,潛在的文件處理開銷是一個非常重要的評價量化指標。我發(fā)現(xiàn),一個容量為50MB或100MB的文件是一個比較理想的測試對象,因為一方面其容量小到足以快速運行,另一方面其容量大到不會在運行時引入測量誤差。測試文件中包含的數(shù)據(jù)類型應(yīng)當是不易被壓縮的——例如視頻文件——從而確保測得的傳輸速度不是一個大文件被壓縮至很小后的傳輸速度表現(xiàn)。
我還建議使用一個包含了眾多小文件的文件夾——我所使用的一個文件夾包括了每個容量為10KB約5000個文件。測試所需的數(shù)據(jù)傳輸時間非常短,這一測試結(jié)果為我們揭示了云文件共享服務(wù)中任何類型文件的傳輸開銷。
但是,確定測試文件的類型僅僅只是一個開始。下面的內(nèi)容將幫助您準確地獲得和理解您的云文件共享服務(wù)基準測試項目的測試結(jié)果。
精確測量是關(guān)鍵
最終,我們需要測量的參數(shù)是大文件的傳輸容量和文件夾中小文件的被處理數(shù)量,這主要取決于具體使用測試套件中的那一部分。為了實現(xiàn)這一目標,您需要知道有哪些對象被傳輸以及傳輸所用的準確時間。雖然這聽上去好像很簡單,但這恰恰正是云文件共享服務(wù)測試過程中最具挑戰(zhàn)性的一部分。此外,在進行測試時應(yīng)關(guān)閉自動同步功能。
為了進行測試,應(yīng)將作為測試基準的文件或文件夾載入至客戶端上相應(yīng)的測試文件夾以便測試上傳,或載入至云界面以便測試下載。
有些云文件共享服務(wù)提供了在同步事件從啟動到結(jié)束期間記錄相關(guān)信息的“易讀”日志。而其他的服務(wù)則可能不會提供非常精確的同步持續(xù)時間,它們使用“小時” 和“分鐘”而不是“秒”來作為同步功能結(jié)束時的狀態(tài)信息。不幸的是,您的測試恰恰需要精確的“分鐘”和“秒”信息來計算傳輸速度。這里有幾種方法可供您使用來測量同步運行時間,但其中最簡單也是最有效的方法之一就是通過使用秒表功能。即,當同步操作啟動時點擊“開始”,而在出現(xiàn)“同步完成”消息時點擊“停止”。
如果您必須對同步功能進行手工計時,那么這是為您的測試文件找到“合適容量”的另一個好理由。例如,如果文件過小,在三秒鐘內(nèi)就運行完成了,那么用戶就很可能會錯誤點擊“開始”和“停止”按鈕,從而給測量結(jié)果帶來極大的測量誤差。而如果運行時間為100秒,那么點擊“停止”按鈕時的二次延遲就不會對測試結(jié)果帶來多大的影響。同樣,如果您選擇的文件容量過大,每次運行都要運行90分鐘以上,那么您就不得不坐在電腦桌前盯著屏幕等待“同步完成”消息出現(xiàn)。
秒表計時的方法可能并不是非常理想,但它可能就是你的最佳選擇了。我已經(jīng)嘗試過很多其他的測量方法,其中成敗各半。有一次,我使用了開源的 WireShark網(wǎng)絡(luò)捕獲工具來捕捉跟蹤整個同步事件以供后期分析使用。該工具為每一個數(shù)據(jù)包都提供了詳細的時間標記。但是,每一種服務(wù)都在數(shù)據(jù)同步操作中使用了專用協(xié)議,因此任何嘗試精確定位同步事件的開始與結(jié)束都純粹是靠撞大運的。
我還曾使用了AutoIT腳本工具來顯示時間并截圖以供后期查看。該工具能夠以任意時間間隔循環(huán)執(zhí)行截圖功能,從而實現(xiàn)所需的測量精度水平。但是,你可能需要在后期從數(shù)百張截圖中手動篩選找出顯示“同步完成”消息的截圖。
報告結(jié)果:度量轉(zhuǎn)換統(tǒng)一單位是有益的
在收集完精確測量數(shù)據(jù)之后,您需要通過一種有意義的方式進行報告。我已經(jīng)看過一些測試者的報告,他們把原始結(jié)果——持續(xù)時間——作為云服務(wù)的最終性能指標。但是,我相信應(yīng)當把測試結(jié)果轉(zhuǎn)換成為一個更有意義、更具普遍價值的指標。對于大文件傳輸,這個基本的性能指標是Mbps。
您還可以使用吞吐量測試結(jié)果,以及計算吞吐量和可用鏈接速度的比值。因此,當一個10 Mbps 的鏈路中顯示5Mbps 的下載速度,那么其使用率為50%,您就可以使用在不同位置運行的測試進行比較,不僅可以比較原始吞吐量,而且可以比較相對于可用寬帶的吞吐量。這是一個比較簡單的計算,它可以向使用者提供一些很有價值的信息。
對于小文件測試來說,Mbps的實際意義并不大。用戶真正關(guān)心的是每分鐘被處理了多少個文件,這一指標可以通過將被處理文件數(shù)量除以以分鐘為單位的時間來計算得到。雖然你可能沒有想到在不同云文件共享服務(wù)之間這個時間會有很大變化,但這就是事實。我曾經(jīng)見過一些測試,其中一家供應(yīng)商能夠?qū)崿F(xiàn)約15個文件/秒的處理速度,而另一家則每兩秒種只能處理一個文件。
云文件共享服務(wù)陷阱
當對云文件共享服務(wù)項目進行基準測試時,這里需要我們有更多一些的思考:
· 測試地點:數(shù)據(jù)吞吐量會隨地點不同而不同,并且其間的差異也是非常巨大的。如果您的用戶群主要位于芝加哥,那么您的基準測試地點就不應(yīng)選擇在舊金山。在兩個地點實現(xiàn)相同的帶寬配置并不意味著其測試結(jié)果會是一樣的,這是因為我們沒有簡單的方法可以了解每個辦公室和服務(wù)供應(yīng)商設(shè)備之間的延遲或帶寬。所以,應(yīng)當在用戶使用該服務(wù)的位置進行測試。
· 異常值:您的測試結(jié)果可能會在一天中的某個時間、一周中的某一天又或者出于未知原因而出現(xiàn)顯著差異。數(shù)據(jù)的傳輸是通過不受您控制的云的,這就意味著其中有可能存在著幾個Mbps的測量誤差。為了解決這一問題,您需要把這一情況告知測試結(jié)果的審查者,即該測試結(jié)果是一個可變的性能測試。您可能需要重復(fù)進行五次測試,剔除其中最好和最壞的結(jié)果,然后對剩余測試結(jié)果求平均值。云的本質(zhì)就是如此,您可能需要在較長的一段時間內(nèi)進行多次重復(fù)測試才能獲得一個具有較低標準偏差的測試結(jié)果。如果您只是簡單地對所有測試結(jié)果求平均值,那么其中的一些粗大誤差將會導(dǎo)致與真實結(jié)果相差較大的偏差,這樣就造成了測試結(jié)果不具較高的可信性。
· 影子副本:這一測試還有可能存在著一些特別的陷阱。例如,您可能會使用相同的文件作為測試對象來進行重復(fù)多次測試,這貌似沒有問題。但是,如果您發(fā)現(xiàn)突然之間這些文件的上傳速度較之前驟然有了較大提升,那么這有可能是因為供應(yīng)商采用了影子副本技術(shù)。如果這些文件已經(jīng)存在于服務(wù)器上(即便是隱藏在回收箱內(nèi)),那么一些系統(tǒng)會非常聰明地檢測到這一點而不再一次地執(zhí)行上傳操作。與之類似,相同的情況也適用于您已下載的文件。您應(yīng)當刪除并清空回收箱以確保您是真正地把這些文件下載到您的同步文件夾內(nèi)。
有條理地使用常識來檢查您的測試結(jié)果的完整性,并把測試結(jié)果轉(zhuǎn)為有意義的指標,那么您就會知道您的下一步選擇方向了。