第14期 2019/11/15
測試：品質、品牌與價值的綜合體現 ——2019至頂網公有云云主機評測綜合分析報告（上）
前言：評測報告沒人看？！（純屬牢騷，可以跳過）
在剛開始進行今年的公有云評測的時候，有人和我說，這種測試沒有必要，沒人會關注這個東西。果然是一句話點醒夢中人！忽然發現，現在評測報告少了，預測分析的報告多了。對于那些PPT廠商來講，這樣做很好理解，他們追求的本來就不是產品的銷售利潤，忽悠出一個概念，獲取投資利潤，至于研發的費用，自然是越少越好，像測試這種自揭其短的行為，自然是不存在的。可是還有很多確實是以產品、以技術為核心的企業也不對產品進行功能或性能的展示，這又是為什么呢？是作者太孤陋寡聞？作為一個專業媒體從業者，想必我的見識還不至于這么淺薄。
主觀臆測一下，可能有兩種原因：
一、多一事不如少一事。
作者曾經深入過許多企業參觀或進行產品測試，給我的感覺是，研發的兄弟太確實不容易了，為了產品可以按時上線，別說996了，724的通宵都有可能，再多一個來挑毛病的，確實不招人待見，自然多一事不如少一事。
二、缺少專業測試工具
云計算的開源生態，可以說是一把雙刃劍，它既降低了用戶的使用門檻，又提升了參與者的進入門檻。免費固然可以得到使用者的青睞，但像測試軟件這種專業而且小眾的產品，免費是養不起身后成百上千的開發與維護人員的，收費的測試工具要想盈利，就只能走定制開發這種路，而缺乏了通用性，很難進行普適性的測試。因此現在對公有云測試就只能依靠一些Linux上的小工具來實現，但這樣做的話，就出現了很多測試精度方面的問題，在下面的測試報告中會具體進行分析。
當然，作為媒體測試機構，我們也在積極和測試以及APM的廠商進行溝通與合作，相信隨著企業對云上應用質量的關注，這類問題會盡快得到解決。
總體上講，問題的根源還是在于廠商對測試的重視程度不夠。對于未來的預期，誰都可以說，張口就可以講。但測試是需要有實實在在的產品的。真心搞研發的廠商，也會有不自信的擔憂，吹出去的牛，并不是誰都可以實現的。不搞研發的，更是樂得忽悠，聲勢做大一點，接盤俠總會有的，大不了上一下失信名單嘛。
但測試是一個對產品的品質、品牌和價值的綜合性體現。在我以前寫的文章里也說到過，中國制造需要升級為中國質造，才能樹立好自身的品牌。這就需要勇敢的把自身產品展示出來，有比較，知不足，才能促進步。現如今，在制造方面，我們已經不弱于任何競爭對手，在創造方面，也正在迎面向前。因此在這里也希望更多有產品，有技術的廠商可以把自身的產品拿出來，通過公開評測的方式更好的向用戶進行展示。這也是我們至頂網持續進行公有云主機產品測試的最主要目的。
最后還有一點需要提醒大家注意的是，對于測試結果，不能依靠簡單的“比數”來評定產品的好壞，要結合測試環境和測試用例綜合的進行分析。下面就是2019至頂網公有云主機評測綜合分析報告正文。
網絡、計算、存儲及云主機可擴展能力的綜合分析
2018年至頂網通過對公有云的測試和用戶及專家調研后發現，那時公有云主機存在CPU處理性能低、內存占用高、云主機可擴展性問題突出之類的問題，并且發現雖然所有公有云主機都可以承受長時間網絡業務訪問，但對于目前問題高發的短時間大流量業務訪問問題上未曾進憲涉獵。（具體測試報告可參見以下鏈接：http://www.meilihuayuanyanglaogongyu.cn/special/CloudTest2018）
因此在汲取去年測試經驗后，今年特意將測試項目調整為針對網絡、計算、存儲及云主機可擴展能力這四個項目的評測之上，被測試的還是去年測試過的AWS、Azure、UCloud、阿里云、百度云、華為云、金山云、京東云、青云、騰訊云這十個公有云廠商的云主機，在本次測試中，依然選擇的是適用于Web應用的2核4G公有云主機進行測試，測試系統盤大小為公有云廠商默認，公網帶寬為5MB，操作系統為CentOS，Web服務為apache，為了更好模擬普通用戶應用，在本次測試中，我們采用第三方開源建站工具WordPress完成測試網站搭建工作，并進行測試。云主機配置可參見不同公有云主機的單項測試內容。各項測試分析結果如下：
云主機Web應用、CPU占用測試結果分析
由于缺乏可以通用的網絡應用性能測試儀表，在本次測試中只能征集熱心用戶在統一時間段對指定測試云主機IP進行Web應用訪問的方式進行測試，并通過博睿數據應用性能監測工具，對請求發生次數、CPU、內存占用情況以及響應時間進行統計。由于用戶行為并不可控，導致測試應用請求分配不平均現象出現，但是從本次測試所收集上來的測試結果來看，還是可以看出被測的公有云主機中所出現的問題。
Web應用請求次數與CPU占用統計圖表
在Web應用請求次數與CPU占用統計圖表中，藍色柱狀顯示的是各個公有云主機最高每分鐘內的應用請求次數，橘紅色柱狀顯示的是公有云主機在測試時候最大CPU占用率。從中我們可以看出金山云的公有云主機雖然具有最多的每分鐘Web應用請求次數，但是其CPU的占用也是最高，達到了99.02%，而每分鐘請求次數與之相近的百度云，它的CPU占用率僅為13.82%。在本項測試中，華為云的CPU占用率最低，僅為5.86%，阿里云其次為6.05%，青云第三成績為7.37%。國外的兩個公有云CPU占用率均在15%以上，AWS CPU占用率為16.05%，Azure CPU占用率為15.19%。雖然AWS與Azure的Web應用請求次數分別達到了643次每分鐘與500次每分鐘，但明顯低于百度云的684次每分鐘，而百度云的CPU占用率雖然超過10%，但也未超出太高，只達到了13.82%
云主機平均響應時間、業務狀態統計及廣域網流量分析
平均響應時間CPU占用率過高會對業務應用造成什么樣的影響？我們通過云主機平均響應時間及業務狀態統計可以進一步進行了解。以下統計數據依然是由博睿數據應用性能監測工具統計并得出。
平均響應時間對比圖表
由于本次測試網絡頁面是利用第三方建站工具調取MySol數據庫內信息生成，目前懷疑第三方建站工具數據調用存在效率問題導致所有公有云主機普遍存在最大響應時間過高現象（首次訪問數據由硬盤加載到內存時的最大響應時間過長），為排除此不確定性因素，在結果對比時，取消了本次最大響應時間對比，只采用平均響應進行比較，測試結果可參見平均響應時間對比圖表。
通過測試結果圖表可以很明顯的看出，金山云的平均響應時間呈現出的一軍突起之勢。平均響應時間高達521毫秒，這意味著絕大部分用戶在點擊在這臺云服務器上的鏈接后，需要經過半秒鐘的等待，才可以獲取到點擊的內容。而為了節省有限的公網帶寬，我們本次測試設計的頁面內只有一張低清晰度圖片和一段文字而已，如果頁面再相對復雜一些的話，用戶體驗將著實令人堪憂。
其它公有云中，以百度云和華為云的平均響應成績最為出色，平均響應時間僅為19毫秒，阿里云僅以20毫秒的1毫秒之差位據其次。其它公有云的平均響應時間表現也都不錯，除了UCloud、Azure與AWS之外，平均響應時間均在25毫秒左右。
在這里需要補充說明一下的是，平均響應時間不但與公有云主機的應用處理能力有關，還與公有云主機的廣域網鏈路狀態有很大關系，如果云主機廠商所能提供的廣域網資源有限的話，也可能會對平均響應時間產生影響，換句話說，UCloud、Azure與AWS這三個公有云廠商在今后，可許更需要在廣域網建設上多增加一些投入了。
業務狀態統計在業務狀態統計對比中，首先要對博睿數據應用性能監測工具提出表揚，它可以根據每條訪問連接的響應情況分為正常、較慢、很慢、停滯、錯誤，五種分別給予統計，可以讓我們清晰的對業務狀態進行統計，但要向博睿提出一個小小的建議，這么重要的功能最好可以做的更加醒目一些才好。
由于無法做到業務請求的平均分配，本次測試中至頂網云能力評估小組不在對正常業務請求進行統計，在業務狀態統計中，只統計了十個被測公有云主機業務較慢、很慢、停滯、錯誤的情況，具體情況可參見業務狀態統計圖表。
業務狀態統計圖表
在業務狀態統計圖表中，我們可以清晰的了解到，由于受到CPU處理能力的拖累，金山云的公有云主機不但出現9次業務較慢、68次業務很慢的情況，還有178次業務停滯和4次錯誤現象出現。
在這項統計中，表現最好的是百度云，只有1次業務較慢情況出現，其次是阿里云和京東云，出現業務較慢和業務很慢情況各1次。其它公有云廠商除了Azure與UCloud之外，業務較慢與業務很慢情況各出現1到3次不等，具體情況可以參見每個公有云主機的獨立報告，這里就不一一贅述了。至于Azure和UCloud在本項統計中分別出現了52次和47次的業務較慢情況，數字比較令人揪心，看來日后確實有必要多增加一些廣域網帶寬的投入了。
廣域網流量上面提到了有些公有云廠商需要增加些廣域網帶寬，然而帶寬就是錢，現在有很多用戶為了節省帶寬費用的投入，也在采用按流量計費的方式對使用帶寬進行付費。那么公有云主機業務應用時候的流量使用情況如何呢，至頂網云能力評估小組同樣也進行了測試。
廣域網最大流量統計表
由于流量分配的不均衡，必然會造成廣域網流量的差異，因此我們將最大請求次數也同時列出來做一個參考。可是發現在最大流量中還是出現了不小的差異。最大流量最高的分別是百度云的4.0MB/s(注：博睿統計結果中確實是大寫的B byte)、AWS的3.6MB/s與Azure的3.14MB/s，與其它公有云主機平均在1.X左右的最大流量存在著很大的差距。雖然他們三家的最高請求次數確實要多于其它公有云主機廠商，但是如果按比例進行換算的話比例又不對等，還是會出現很大差距。不知這個問題是統計數據造成的，還是由公有云主機造成的，看來今后還有必要針對這個問題進行更進一步的測試，仔細看一下，流量到底都去哪兒了。
內存占用在去年公有云主機測試時，曾發現被測云主機普遍存在內存占用過高情況，今年同樣對公有云主機系統內存占用情況進行了測試，下面內存數據同樣是由博睿數據應用性能監測工具記錄，最高是記錄的在正常業務訪問中最高內存占用結果，最低為訪問結束后最低內存占用結果。具體數據參見內存占用圖表。
內存占用圖表
通過內存占用圖表可以看出現階段各公有云廠商公有云主機的內存占用情況均出現很大好轉，除了金山云可能是因為在正常業務訪問中出來過多等待和錯誤連接占用了過高的內存之外，其它公有云廠商的正常業務訪問最高內存占用基本均在2.5G左右的水平線上下，而訪問結束后內存恢復情況也都比較理想的保持在0.7G左右。由于結果相差不多，就不再逐一進行分析了。
公有云主機異常流量沖擊下健康狀況測試
以上都是針對正常業務來進行的測試，但是在業務應用中，從來不是一帆風順，會有很多異常情況出現。于是接下來至頂網云能力評估小組就會人為的制造一些異常，來看一下在異常狀態下這些公有云主機的健康狀況如何。
為此，至頂網云能力評估小組采用在服務器端上用ab同時保持50個用戶訪問（ab參數-c 50）并建立1萬連接和間隔數分鐘后再發起同時保持50個用戶訪問并建立10萬連接的方式，對公有云主機高并發應用處理能力進行測試。由于博睿數據的監測工具在云主機CPU跑滿的情況下無法提供準確監控數據，因此選用Apache AB所提供的請求速率Requests/s結果進行統計。
Apache AB應用性能測試圖表
在這里需要事先強調一件事情，Apache AB應用性能測試的數據，本身沒有過多可以相互攀比的意義，此項測試是為了考驗在CPU被業務處理打滿之后云主機是否還可以正常運行。在上面測試中公有云主機正常業務應用中，每分鐘處理300-500左右也就是每秒種處理5到10個業務應用，已經是單臺云主機可以正常處理的極限了，當正常應用接近這個極限之前就需要考慮如何對云主機進行擴展，以保障業務的正常可持續運營。
上面的測試也可以充分說明這個問題，金山云的Apache AB 在1萬次訪問請求時，排名第二，在10萬次訪問請求時排名第一，但是在測試完成后，無論是遠程管理的客戶端還是公有云的控制臺對其進行操作均無法進行響應，只有再通過控制臺進行重啟后，才能繼續進行操作。也是本項測試中唯一一個沒有經受住異常流量考驗的公有云主機，其它公有云主機均成功的經受住了考驗，可以在突發異常時穩定運行。
從上面的測試中我們可以了解，CPU的處理能力，與網絡應用息息相關，雖然在正常應用流量測試中，絕大部分的公有云主機CPU使用并沒有達到一個很高的數值，但這是因為為了測試所搭建的網頁簡單，沒有過多互動性內容而導致的。公有云主機的CPU處理能力到底如何？為什么至頂網云能力評估小組一直提倡采用雙核云主機？網絡、計算、存儲中云主機的系統盤存儲能力又是如何？這些問題我們會在下半部分文章中再繼續為大家進行解讀。
本文章選自《AI啟示錄》雜志，閱讀更多雜志內容，請掃描下方二維碼
