導讀  ID:TOP100case

淘寶網的效能測試自動化平臺具備了分散式、高併發、低成本、可擴充套件等特性的效能測試平臺工具，它包括效能專案管理、環境管理、指令碼管理、場景管理、任務管理、監控管理、結果管理等模組，以及前端效能測試模組、效能測試報告模組、效能缺陷模組、和效能基線模組等，後臺還有完善的分散式壓測引擎管理平臺。

本文結合效能測試在企業雲架構上的應用案例，介紹淘寶網的效能測試從無到有經歷的階段，同時介紹自主研發的自動化效能測試平臺誕生的條件和過程，解析如何使用效能測試的方法保障企業應用的效能，同時如何構建一個性能自動化測試平臺。

（全文共9698字   預計閱讀時長：12分鐘）

淘寶網效能測試團隊成立於2009年1月，當時團隊只有2個人。從那個時候起，團隊成員便開始參與或負責淘寶網的核心技術架構變革的效能測試工作，當時的“五彩石”專案就是團隊的一個關鍵里程碑，它代表了效能測試團隊的第一次大規模實踐和產出。

團隊剛好經歷淘寶網的技術由Java初期時代到大規模分散式系統時代，也經歷了在這個時代所產生的問題。

效能測試團隊發展至今，其成長過程大致可分為業務發展、平臺發展和產品上雲三個階段。

 淘寶網效能測試的演變 

淘寶網效能測試的發展過程如表1所示。

表1  淘寶網效能測試的發展

●

 1.1 業務發展階段（2016年1月到2011年8月）

它是效能測試團隊成長的基礎，是效能團隊、積累和總結的過程。這個階段在大量的做專案和日常的業務測試，每個成員都同時承擔著超過5條產品線的專案效能工作，同時測試的專案最多時可達十餘個。在這種高強度高壓力的業務測試歷練中，團隊的每一位成員都擁有了豐富的業務測試經驗，對今後團隊的發展、技術發展和平臺發展都起到了重要的基石作用。

在這個團隊雛形時期，產出了具備一定參考價值的《效能測試白皮書》、《效能測試寶典》、《效能測試大型專案壓測模型》、《效能測試常用工具和使用方法》、《效能測試流程》等文件；同時也產出了效能測試的各種方案，包括《效能測試設計方案模板》、《效能環境守則》、《效能環境目錄規範》、《效能測試報告模板》、《效能測試過程檔案》、《效能測試環境搭建規程》、《效能測試流程圖》、《效能測試日報模板》、《效能測試資源申請模板》等，這些文件和方案直到現在對於業界新人仍然起到了入門、學習和引導的作用。

● 1.2 平臺發展階段（2011年9月到2013年8月）

它是效能測試團隊創新的階段和過程。業務發展到一定階段，必然需要產品、平臺的支援才可以走得更遠，更加專業，2011年的8月，團隊的TL意識到以下幾點：

• 我們的工具仍然是花費昂貴的Loadrunner；

• 人手幾臺Loadrunner物理機，所做的專案仍然有限；

• 大專案的支援，高併發的支援，仍然做的不好；

• 工具和人力都成為制約專案效能測試發展的瓶頸；

• 淘寶普遍使用HSF介面的壓測需要封裝成http請求，工具使用存在一定的侷限性；

• 更多人想參與到效能測試工作中來。

在當時的系統工具和平臺部門下，我們這樣一個專業的效能測試團隊，卻沒有一個適合自己、適合淘寶的效能測試工具和平臺，這種情況的改變迫在眉睫，去除Loadrunner更是當務之急。

在這個階段，我們為了解決效能資源申請和透明化、流程化的瓶頸，產出了“T-work效能中心”；為了解決線上線下效能對比的問題，和核心團隊合作，開發了“線上線下跟蹤體系平臺”、“線上線下容量評估平臺”，也就是CSP的前身；緊接著團隊自己開發了“效能自動化測試平臺-PAP”當時還是以Tsung為主效能測試壓測引擎，在平臺積累了一定量的使用者以後，我們繼續開發了核心壓測引擎“分散式壓測引擎-Trunner”、“壓測引擎管理平臺-Trunner-console”、“前端效能測試平臺”等。

同時我們除了前端效能測試，也開始著手研究客戶端效能測試方法（旺旺）、無線效能測試方法等，使得效能測試在支援阿里集團各BU上更加專業、更加廣泛，且朝著體系化、平臺化和系統化的方向發展。

● 1.3 共建和雲測試發展階段（2013年9月至今）

在這個階段，我們團隊邀請了更多的人員參與共建。為了適應發展，團隊拆分為了平臺和業務兩個分支。平臺的同學繼續維護目前的PAP，同時提高使用者體驗；而業務的同學則分拆到各個業務線。其目的一方面是幫助各業務線建立一套適合自己產品線的效能測試的基線、標準和方法，同時建立迴歸體系，保障線上產品的穩定；另一方面幫助各業務線測試同學的成長，讓效能測試的範圍覆蓋面更廣，使得面向人人效能測試的終極目標更進一步。

這其間，我們團隊獲得了技術質量部共建優秀團隊獎，同時產品共建支援了包括QR、TMD、DUBBO、QTEST、DDOS等更多協議和工具的效能測試工作；也支援了作為JAE的對外核心效能測試平臺的工作，同時我們通過雙十一和聚石塔的合作，逐漸開始向外部客戶發展。從剛開始的ISV到目前的阿里雲所有客戶，以及面向更多的客戶，基於PAP開發了支援ISV雙十一等活動的JST_PTS和支援阿里雲客戶的ALIYUN_PTS，同時也圍繞著阿里雲客戶的需求，融入DTS和管理平臺，引入計費模式，最終使得PTS對外正式釋出收費，向雲測之路又邁出了堅實的一步。

 效能測試評估和流程 

在支援外部客戶效能測試的過程中，我們發現，大量的使用者認為效能測試只是傳統的壓測，使用壓測工具，配置一個url或者錄製一個url就完成了，然後直接開始壓測。

其實工具只是一個輔助手段，一個工具有大量的配置規則，一個url也有很多的內容組成，要找到一個適合自己的壓測工具、壓測方法和壓測手段，同時也要了解壓哪個url，以及壓測url的哪一部分是適合的。

例如一個頁面有以下的問題：

第一次測試，網站併發數沒有超過35個，大量超時。

第二次測試，網站上做了優化以後，併發使用者數100以內時響應 5s ，200以內時90%響應在15s以上，隨著併發使用者數的增加，頁面響應最高可到20多秒。

注：測試工具Loadrunner

我們該如何評估和分析呢？

首先我們要了解這個URL的訪問過程如圖1所示，分別從訪問路徑和URL包含內容來分析。

 圖1  URL的訪問過程

這裡，URL經過瀏覽器，通過網路進入伺服器；再通過網路，進入資料庫儲存，最後返回給使用者。

所以效能的評估也要從這幾個方面去分析，我們壓測的是不是這幾個路徑，需要壓測什麼，需要怎麼壓。

根據以上的路徑分析出：

• 使用者的響應時間是指整個頁面載入時間；

• 壓測的客戶端是否成為瓶頸；

• 使用者測試的網路頻寬是否成為瓶頸；

• 使用者的伺服器、資料庫毫無壓力；

• 使用者的測試方法存在問題。

● 2.1 前端效能測試

檢視圖2我們發現，一個頁面的訪問，90%以上的時間都消耗在了前端資源（js、css、img）的載入和渲染上，只有5%～10%是消耗在伺服器端的響應上。而例子中使用者使用loadrunner錄製的指令碼來做的壓力測試（壓測），就是帶著所有的靜態資源來壓測，而一個頁面有時候會很大，假如是1兆，那麼普通網絡卡最多就是千兆網絡卡，有些PC機甚至只是百兆網絡卡（bit），換算下來一秒鐘最多訪問100M/秒（千兆網絡卡），所以對於一個1M（Byte）大小的頁面，TPS最多就是100，已經達到網絡卡的極限，再多的併發也沒有用，所以就會遇到響應時間上升的情況。

圖2  頁面訪問的時間消耗分佈

反觀淘寶的靜態資源都是存放在CDN上，而且有獨立域名，這樣使用者不會和伺服器響應共用一個網路，就不存在網絡卡的瓶頸。

淘寶網的效能測試主要針對5%-10%的html伺服器資源進行壓測的，基於以下兩個因素：

• 靜態資源都沒有問題，所以無需壓測，也無法壓測，不同使用者的訪問cdn站點不同。

• 採用區域網方式，儘量忽略網路的影響。因為使用者的網路是無法真實模擬的，那麼只要提高伺服器併發就可以了，不需要關注由於網路導致的波動等情況，保持伺服器效能和穩定，那麼目標就完成了。

所以，淘寶網的效能測試一般頁面響應時間是在300毫秒以下，介面的響應時間在70毫秒或100毫秒以下，就是這個原因。

雖然伺服器端的響應只佔整個頁面響應的5%～10%，但是這個響應是所有使用者體驗的首要響應，只有伺服器端儘快的響應，才能夠讓後面基於html上的其他資源儘快響應。所以保障伺服器端的響應是這個效能測試過程中最重要的環節，同時在保障伺服器端響應時間的基礎上，更要保障伺服器的穩定，也就是測試高併發的情況。

那麼是否前端就不需要關注了呢？答案是否定的。前端的測試方法由於是瀏覽器客戶端訪問的方式，所有的靜態資源在網路環境滿足的條件下，需要客戶端使用者自己的電腦去渲染，包括JS執行等，所以前端的測試有其自身特殊的方法，常見的前端測試工具包括以下產品，如圖3所示。

圖3  常見的前端測試工具

而PAP也有基於WebPagetest的前端效能測試工具，具體的使用方法這裡就不再介紹。經過測試後，可以優化的點包括：

• 靜態資源無快取；

• JS較大，無壓縮，存在重複請求；

• JS位置不合理；

• 外部CSS依賴較多；

• Banner圖片較大，且多，無壓縮；

• 後臺介面請求較多，可以合併；

• 頁面存在請求失敗和跳轉的外部資源；

• 外部依賴介面較慢；

• 頁面請求數較多，主要是JS和CSS重複載入。

• …

優化效果對比如圖4所示。

 圖4  優化效果對比

Loadrunner裡面，去除靜態資源的選項如表2所示。

表2  Loadrunner裡去除靜態資源的選項

● 2.2 伺服器端效能測試

瞭解了前端效能測試的原因和方法，我們來看伺服器端效能測試方法。

首先，需要了解一下效能測試的指標，如表3所示。

表3  效能測試指標

 圖5  load

圖6  效能測試的指標GC

● 2.3 PV與TPS的分析

對於一個性能測試，最關鍵的TPS是怎麼換算的。例如使用者的預估或者實際的網站訪問（PV/天）符合一個正態分佈，如圖7所示，從0點到24點，那麼使用者高峰訪問的每秒PV，就是我們所要計算的TPS，也就是我們壓測的效能目標。如圖8所示。

 圖7  PV曲線

按照80/20原則，我們需要找到整個面積的80%消耗在多長時間內，比如我們將訪問的圖拆分成不同的矩形，計算出每個矩形的面積，然後倒序排列相加，找到80%面積的點的時間如圖8所示，大概是7/16。

圖8  PV訪問圖拆分成不同的矩形換算TPS

所以，平均一天的PV就是PV×80%/（7/16）=X，這個X是平均值，由此計算出它和高峰的係數，PV（F）/X=Y，Y就是係數。那麼，使用者只要知道他的一天PV是多少，根據這個公式就可以計算出高峰PV，也就是所說的TPS，然後把它作為效能測試的目標來壓測。

● 2.4 測試方法詮釋

 圖9   系統處理能力的變化趨勢

圖9顯示了效能測試過程中，隨著壓力的增加，系統處理能力的變化趨勢：

a點：效能期望值

b點：高於期望，系統安全

c點：高於期望，拐點

d點：超過負載，系統崩潰

我們可以做的效能測試a點（效能測試）、b點（負載測試）、c點（壓力測試）、d點（異常測試），以及基於這幾種型別的長時間穩定性測試，如表4所示。

表4  4種類型的穩定性測試

一般測試，很難將伺服器給壓至崩潰，壓測到負載測試後，TPS便相對穩定下來，響應時間反而增長，所以當壓力到TPS的增長率小於響應時間（RT）的增長率時，這個時候的併發，就是系統所能承受的最大併發，再大便無意義，也不便於發現和分析問題。壓力測試通過標準如表5所示。

表5  通過標準

 基於雲產品的入口網站效能優化案例

● 3.1 背景

不久前，有幸經歷了一個規模較大的入口網站的效能優化工作，該網站的開發和合作涉及多個組織和部門，同時上線時間非常緊迫，關注度也很高。

下面將以此項工作作為典型案例，與大家分享一下基於雲產品的入口網站效能優化，內容包括如何使用PTS的壓測工具、壓測前的效能問題評估，以及壓測執行後的問題分析、瓶頸定位等。

該入口網站的伺服器存放在華通和阿里雲的平臺上，所以對華通和阿里共建的雲平臺安全及應急措施要求也非常高，需要團隊給予全力的保障和配合。

先介紹一下PTS，效能測試服務（Performance Test Service，簡稱PTS）是集測試機管理、測試指令碼管理、測試場景管理、測試任務管理、測試結果管理為一體的效能雲測試平臺，可以幫助您全方位的評估雲上系統性能。如表6所示。

表6  PTS的產品優勢

本次優化主要是使用了該測試平臺服務對客戶搭建在ECS上的伺服器進行多種型別（效能測試、負載測試、壓力測試、穩定性測試、混合場景測試、異常測試等）的效能壓測、除錯和分析，最終達到滿足期望預估的效能目標值，且上線後在高峰期也滿足了實際的效能和穩定要求。

● 3.2  評估

本次效能測試過程的參與者包括了阿里雲應急保障小組等多部門人員，網站為外部供應商開發，阿里雲提供雲主機和技術支援。

該網站前期已由其他部門做了驗收工作，並進行了完整的效能測試。報告顯示，效能較差。第一次測試，網站併發數沒有超過35個；第二次測試，網站做了優化後，靜態頁面縮小，併發使用者數100內5秒，200內90%響應在15秒以上。隨著併發使用者數的增加，頁面響應最高可到20多秒，而且訪問明顯感覺較慢，聯絡了阿里雲的技術支援，希望能夠幫助診斷效能問題，給出優化建議。真正的測試優化時間只有不到3天時間。如表7所示。

表7  優化後的測試時間

經評估得出最終的測試目標要求：帶頁面的所有靜態資源，響應時間必須小於5秒，同時併發訪問使用者數最低500，TPS根據實際的結果得出。

● 3.3 分析

結合Loadrunner的使用經驗，團隊的第一感覺就是使用者測試方法可能有誤，一個頁面載入對於阿里的應用來說，都是1秒以下的，也就是毫秒級別的，不會出現幾秒的現象。而使用者測試結果都以秒來衡量，所以測試頁面肯定是帶了靜態資源一起壓測的。

這樣的測試，其實模擬了使用者的整個頁面訪問情況。它有一個弊端，就是頻寬。一般人的電腦都是百兆網絡卡，最好的伺服器目前也只是千兆網絡卡，萬兆很少見，如果一個頁面按照500K的大小來計算，百兆網絡卡的壓測客戶端，最大1秒鐘併發約25個（100M*1000(Kb)/8/500(KB)=25），網絡卡打滿後，再增加壓力，增加併發，TPS不會升高，而響應時間則會升高，才會達到1秒，5秒，甚至20秒，有時候還會超時。

但這種方法客戶認為最接近使用者體驗，屬於頁面全部載入完了。我們分析，一方面瀏覽器載入靜態資源肯定不是序列的，同時還有js的執行時間無法模擬；另一方面靜態資源都是會快取的，如果每次壓測都要下載靜態資源也不妥。所以這種方式並沒有真實模擬使用者訪問的，如圖10所示。當然也不排除有些測試工具是可以模擬這種併發的，至少在該專案中，沒有這樣去做。

圖10  頁面載入時間分佈圖

注：頁面的響應時間88%左右都消耗在前端資源載入上，伺服器端消耗只佔到了頁面響應的12%左右。

這種場景適合如JS、css、image等靜態資源和後端程式碼放置在同一臺伺服器上的情況。

一個網站的響應一般由前端、網路、伺服器和資料庫四部分時間組成，如圖11所示。前端主要是減小頁面大小，減小頁面請求數，優化頁面js；網路主要是使用CDN，優化連線數；伺服器主要是優化Apache、Tomcat、java程式碼等，資料庫則優化sql語句，優化索引，優化資料儲存等。

 圖11  組成網站響應的4部分

● 3.4 測試和優化

先不討論原來的測試方法是否準確，我們首先以測試和優化為目的，對該入口網站進行測試和分析，內容包括以下方面。

3.4.1 頁面前端分析和優化

對頁面的優化從前端開始。首先通過PTS的前端測試工具（未開放），再結合Yslow（yahoo前端測試工具）、Pagespeed等掃描，發現以下問題並進行優化。

• 靜態檔案無快取，伺服器配置解決；

• Js較大，無壓縮，同時存在重複請求，最多一個js載入4次，已做壓縮和減少；

• Js位置不合理，阻礙頁面載入；

• 外部css考慮本地實現，減少呼叫；

• Banner背景圖片較多，無壓縮，建議合併；

• 頁面1的後臺.do有4個，減少為3個；

• 頁面2的後臺do有2個，減少為1個；

• 存在載入失敗連結，404失敗，同時次數非常多，更換為cnzz；

• 頁面載入外部資源失敗（qq等），且不穩定；

• 分享功能比較慢；

• 外部資源建議非同步實現，目前全部是jquery渲染，iframe巢狀，時間資源限制，後期優化；

• 儘量減少或者不使用iframe；

• 頁面請求數太多，主要是js和css重複載入問題和圖片較小導致的。

第一階段性成果：在進行了第一輪的前端優化後，效能提高25%，首頁響應從1.5秒提高到1.1秒，並且前端優化持續進行。如表8。

表8  前端優化的結果

相關推薦