今年的天貓雙十一以912億的交易量落下帷幕，在短短的24小時里，天貓創造了最高4500萬人同時在線，系統交易創建峰值達到每秒鐘14萬筆，支付寶的支付峰值達到了每秒8.59萬筆，全天支付筆數達7.1億筆。如此天量的訪問和交易，給天貓平臺帶來了前所未有的訪問壓力，天貓的IT運維人員是如何進行雙十一IT性能保障的呢？
請看云智慧工程開發VP劉志達（Jason Liu）為您帶來的云時代壓力測試新方法。
Jason：大家下午好，我是云智慧的Jason Liu，主要負責公司技術部分工作。很高興有機會和大家一起交流一下性能壓力測試方面的話題。我要給大家介紹的是云智慧剛剛推出的壓力測試產品叫壓測寶。我們所說的壓測和傳統的壓測有很大差別。
從案例看用戶需求
我們壓測產品主要從云的層面給系統做性能測試。先來看兩個案例，大家多多少少訂過火車票，12306剛上線的時候就出現過癱瘓問題，尤其是春運期間。雙十一剛剛過去，阿里剛開始推雙十一的時候支付環節也曾經癱瘓過。所有這些都指向一個問題，就是系統上線之后的性能問題怎么解決。這部分問題一旦發生，對整個業務影響是致命的，像阿里宕機一秒鐘就可能會造成了百萬級的損失。
同樣作為電商網站，在雙十一的時候，是否還敢去做促銷？
我們看阿里巴巴是怎么做的，阿里現在除了國內還開始包括海外，雙十一它對系統壓力是巨大的，阿里是如何搞定這件事的？

在2013年阿里已經改變了對性能測試的方法，他們做到了一個全鏈路壓測。全鏈路壓測和傳統壓測完全不同，傳統壓測解決的是單點問題，看服務器負載能力可不可以，比如內部放三臺負載機就去壓一下，看能不能承受2000的并發或者十萬用戶訪問。這是傳統的壓測。
但是一旦到線上，引流過來以后，帶來的結果是什么？有可能系統掛掉了。這個原因是什么呢？就是因為我的測試環境和生產環境并不一樣，我的測試壓力制造都是在實驗環境下做的。
阿里2013年做的全鏈路壓測，做成具有真實環境的狀態，讓壓測變成有確定性的評估，能確定上線后到底什么狀態。他怎么做的呢？阿里的全鏈路壓測覆蓋了前端系統、網絡、DB和基礎架構等整個系統環境，在測試環境里把真實業務完全還原了。
要做這件事的不只是電商，前幾個月我和建行的人聊的時候，他們的網銀系統也要做這樣的事，模擬生產環境一樣的做測試環境，做真正的壓力訪問。他們要做交易鏈路上真實的限制，包括網絡帶寬、各級分級負載處理，甚至系統中間放了很多安全設備對性能影響有多大，都能通過全鏈路壓測能發現，不僅僅發現性能問題和服務器本身的負載能力。
中國只有一個阿里巴巴，他們有五千個后臺工程師負責整個系統后臺維護，才能保障他們雙十一活動的正常運轉。現在阿里使用了全鏈路測試以后，只要有一千個后臺工程師保障就夠了。但大部分公司都不具備這樣的實力，可能公司也才幾百個人，雖然業務沒有阿里龐大，更不可能放那多后臺工程師去維護。
“云測試”的新方法
那么這種企業該如何解決性能問題？

云智慧提供了一個解決方案，通過云測試的方式幫企業徹底解決業務系統性能問題，那我們怎么做的呢？這里邊有一個整體的結構圖，在壓力測試中，這邊是業務系統，包括負載、服務器、網絡，這是整個的真實測試環境。我們如何制造壓力？云智慧在云端，比如阿里云、×××、Ucloud上，我們放了很多壓力機，就是制造壓力的服務器。 它通過云端制造壓力訪問系統，這個訪問基本上跟實際生產環境的用戶訪問一致。因為這些服務器分布在不同的地區，而且它的訪問量也很容易起來。通過這種分布式的方式，從云端來制造大量的壓力，來模擬真實的用戶訪問，很容易測試系統上線之后是不是能夠經受住預計五百萬的用戶訪問和五千的用戶并發。

接下來我們看這種測試如何做？比如說在某電商網站，我們做了三千并發用戶，這是我們錄入的測試腳本，錄制好后，就模擬實際用戶跑這個腳本。當壓力增加到三千用戶的時候，我們會發現在幾個業務處理環節，響應時長和處理能力都變得比較差，這些業務是最關鍵的，從加入購物車到支付的環節，這里可以看出購物環節的性能是瓶頸。
這上面有幾個數字，我稍微解釋一下。一個是所花的時間，平均時間，最長時間和最短時間。我在做一段時間的并發壓力測試下，系統性能最好、最差和平均數據都能拿到。但是有一個非常重要的數字就是90%，所謂90%什么意思呢？就是所有用戶請求里90%用戶的請求狀態是多少？它代表了絕大部分用戶。這個數字更具有參考意義。
在測試過程中我們也可以制訂一些壓力策略，比如說購物環節可能轉化率非常高，80%的用戶，甚至85%的用戶都會走到這一步，就可以設置這部分請求數量我分配80%，也就是說我三千并發里有兩千多并發在這部分，還有其他的幾個非關鍵性業務還會占10%，按照這樣的比例分配請求。這些都是動態可調的，我們做的過程中會按照這個策略分配訪問用戶來跑這個腳本。
在測試過程中除了看到速度還要看到一些出錯的情況，并發從兩千到三千這個過程中，我會產生多少失敗的請求？失敗請求數量有多少？隨著壓力上升，比如說我們在三千并發的時候，會有一些環節撐不住，就會有一些請求出錯。偶爾有一兩個出錯對系統影響并不嚴重，屬于可接受范圍，但是像這種一個小時出現上千次請求失敗的情況，就是一個非常嚴重的問題了。我們可以把嚴重的問題挑出來，針對性進行問題分析，到底是什么原因導致的。
我們可以分析不同的用戶壓力下，如并發用戶一千、兩千、三千時候的問題表現，我們在這次測試的時候，達到一千并發訪問的時候，出現了502和504的錯誤。當我把壓力加到兩千的時候，我們看到購物車出現瓶頸了。出現瓶頸的原因我們從帶寬上看，在一千用戶的時候帶寬消耗一百兆，按正常來說兩千用戶應該消耗兩百兆帶寬，但是沒有消耗到這么多帶寬，我們認為業務處理能力下降導致。
那么繼續分析下降的原因是什么，這部分可能要聯合開發和運維一起做測試。他會根據每個接口進行分析，比如剛才我們看到的這個接口，它是在商品購買的時候并發處理做得不好。每一個商品有一個可賣數，例如準備了五千個，下單的時候我們會在每一個用戶下單購買這個商品的時候，把可賣數減1，直到賣完。開發在這一步驟的處理有問題，他用memcache來緩存，但是這個緩存并沒有真正做到緩存的作用，僅僅做了一個中間數據庫的過渡。他在每下一個單時都把可賣數取出來放到memcache，但是正常來說每次大家都應該來讀memcache，一直到這可賣數為0。但實際情況是他每次都重新創建緩存，所以多線程并發的時候，尤其搶購的時候，導致了一個線程把緩存創建完，另外一個線程就把緩存干掉了，之前這個線程再去讀的時候讀不到數字，由此集中產生了大量的錯誤。
這種問題在功能測試階段往往是發現不了的，只有在性能測試的時候，上了真實用戶訪問壓力的時候才會曝露出來，然后我們才能有針對性的做分析。首先我們得知道到底哪個請求出了問題，否則對用戶表現就是下單失敗，但是為什么失敗卻沒有人知道。
我們目前做過的客戶有很多，像太平洋保險、中國海運、中國移動的咪咕、中國電信、蘋果iCloud等。壓力測試隨著互聯網發展越來越受重視，尤其是大家越來越關注用戶體驗的時候。
傳統工具的缺陷
壓力測試這項工作在很久之前大家就在做了，只要有測試團隊的，壓力測試一定會有。過去壓力測試的做法實際上都是工具性的，所說的工具如JMeter和LoadRunner，我們稱之為上一代產物，他們有一些缺點，一個是適應性比較差，需要對一次測試準備大量的環境，如要準備很多臺壓力機，然后錄制腳本，做得好可以進行一些分發，但是這些機器終究要準備的。

尤其對業務量比較大的企業，比如我們要制造50萬或者一百萬用戶訪問的時候，一臺物理機的并發模擬用戶在500到1000的樣子，就需要準備大量物理機，成本比較高、而且時間很長。像某些客戶以前為了做性能測試，準備機器有時候就需要幾個月的時間。
另外一個最大的問題是實驗室環境，我們所說實驗室基本在內網把環境搭好，而內網的網絡條件都不會差，這時候用機器去壓，有的時候并沒有問題。但是真正上到生產環境，網絡帶寬和前端的負載機制，甚至前端加了安全措施都有可能對性能產生影響，導致服務響應慢或者宕掉。
壓測寶的優勢

壓測寶有幾個優勢：1、速度，這個速度主要是部署，因為它整個測試是在云端發起的。利用了云的優勢，在云端可以幾分鐘開出來一臺壓力機。我要模擬十萬用戶訪問，開了五十臺服務器，我想增加到十萬，再開五十臺就好了，不需要在每臺機器上做準備工作。從過程來說，整個我們開壓力機的時間基本上跟云主機的啟動有關，大部分測試在半個小時內就能把壓力測試環境準備好，而傳統的工具基本上在一個多月。
2、分布式的環境，我在云端不同地區發起的用戶訪問，它不是在內網發起的，所有的架構、鏈路都會到，這是一個真實環境，因此可以大規模的，一百臺、兩百臺甚至一千臺都沒有問題，而內部準備的時候還是受制于自己買的服務器、服務器的容量的限制。
3、性價比，我節省了人工，不需要那么多人準備壓力環境、也不需要那么多人做壓力測試，都由系統和云解決了。另外我可以在任何時間、任何地點來做，因為訪問云是不受任何限制的，意味著發起壓力的時候也不受限制。我們可以同時對多個系統做測試，都是在云端發起，只需要替換一下腳本就可以。
壓測寶也在改變壓力測試的標準。
一個是從研發到生產可以做高頻度測試。因為在云端，想用就開，不想用就關，隨時來做。第二可以從用戶端真正做到全鏈路測試。

第三是實時統計分析，壓測寶里的數據是實時統計的。用其他的測試方法，測試條件包括壓力數量準備好之后，一般都會跑完，比如上五千并發，結果系統直接壓死了。我們是可以隨時調整壓力的，隨著壓力逐步上升，系統的性能數據動態呈現。壓力從一千加到五千，兩千的時候就像我們剛才看到的數據，性能已經在下降了，大量出錯，這個時候沒有必要繼續往下壓。我們可以停掉，也可以把壓力往下調，比如兩千的時候出現嚴重問題了，那我調到一千五。根據系統目前狀態，在保障業務正常運行的情況下看看能撐住多少用戶訪問，通過壓力的上下調整找到這個點。也許我找到1300并發的時候，系統出錯、性能都在容忍范圍內。就說明系統現在承載能力在這個范圍。
第四是配套的監控機制，壓測寶能做到這一點依賴于一個監控機制，這個監控是可以接收即時數據，我們做了很多數據呈現的報表，這些報表也是隨著壓力變化呈現實時的曲線，所有數值都是在變化的，所以我們可以看到它的狀態。
第五是測試周期的縮短。現在我們在給很多客戶做的測試，其實花時間最多的是腳本錄制。腳本錄制完之后只需要幾分鐘、十幾分鐘壓力測試準備好可以去測了。對腳本錄制這部分，大家做的都是差不多的，比如壓測寶，都是通過我們提供的錄制工具，像實際訪問一樣，點瀏覽器一步一步操作，操作結束之后腳本錄制完成。但這只是最初的腳本，真正要測試的腳本，有的時候要排除很多內容，比如CDN上的資源。很多時候壓CDN是沒有意義的，需要把CDN的資源替換掉，只留下服務器端發出的實際請求。另外有一些業務存在等待時間，中間也可以穿插等待時間。?
壓測寶的優勢有哪些？
從使用層面上，我們不需要再做大量重新的學習，學習成本很低。錄制腳本這塊我們也會幫助來錄。我們現在做的壓力測試，對客戶來說只需要把業務告訴我們，剩下的事情基本上不用管，所以做得很快。同時我們只要準備好一次之后，如果業務沒有大的變化，以后每次直接跑腳本就可以了，完全不需要客戶自己花太大的精力重新準備。原來的壓測方式需要一個月測一次、兩個月大的上線測一次，現在可以做到只要有版本更新迭代就可以去測。
我們在云端我們有很多合作廠商，幾乎主流的云服務商我們都能在它上面測壓力。測試規模可以從幾萬到幾百萬，主要取決于云主機開了多少，我們就能測試多少。這個壓力量是沒有一個上限的，這是傳統壓力測試在內網很難做到，因為硬件投入就很難。
報表是實時統計的，可以邊做邊看。
我們可以在測試過程中解決性能問題，解決問題不是單純靠這個工具。本身云智慧是做性能方面的監控和分析的，壓力測試能夠幫助發現問題，我們的APM產品透視寶可以分析和定位問題。一般的話都是搭配來用，通過壓測寶測性能、發現性能問題，通過透視寶分析和定位性能問題，而控寶能夠做的一些是對基礎服務的分析，這幾種產品我們都有大量的實際案例。

今天把壓測寶產品做了簡單介紹，還是概念性的。因為在座的都是運維，跟測試部門不同，測試部門對這方面的需求比較多一些，一般來說做壓力測試，尤其線上的壓力測試有兩種，一種是測試環境上線前做的，還有一種可以在上線后做。很多系統已經上線了，上線前沒有做過壓力測試，也不知道能撐多少的訪問量，什么時候做系統升級，也沒辦法做預測。我們給不少用戶做過這樣的事情，用壓測寶來做上線后的壓測。
用壓測寶做這件事最大的好處是壓測寶能夠逐漸調整壓力范圍，也就是說不會像常規壓測，設5000，一下就爆了，我們可以找到系統性能的范圍，第二能找到性能問題出現在哪里，所以這個場景下用的多一些。另外就是測試環境來做，但不論怎么用壓測寶做壓力測試，基本上需要運維部門來陪伴。
以上是我今天關于壓測寶的分享，接下來是用戶答疑環節，大家有什么問題可以提出來。

提問：您剛才提到壓測寶監測功能比較強大，如果要看服務器壓力，不知道壓測寶怎么看？
Jason：壓測寶重點不在這塊，但會提供一套比較基礎的監控，比如對服務器的監控，比如CPU內存、流量。我們一般搭配監控寶、透視寶，向中間件、數據庫在壓測過程中都有可能出現問題，配套的這些東西還是要做的。

提問：可以在內網監控嗎？
Jason：可以在內網做，但是需要在測試的時候跟外網不同，和傳統的方式類似，缺點是用戶訪問量不容易加上去，要做的話要加很多壓力機。

提問：壓力機都在云端？
Jason：對，其實我們還是推薦云端，如果放在內網跟真實環境還是有差異。當然像銀行、政府機關因為有政策要求，說必須在內網環境，不能出公網，如果有條件的話，絕大部分環境都可以出公網，因為業務都在公網，這種訪問最好在公網來做，自己省力，測試效果比較真實。

提問：壓測寶和基調的測試一樣嗎？
Jason：其實并不一樣，因為基調檢測是模擬用戶發一個單次請求來做監控。壓力測試是把一個測試用例讓大量用戶，比如十萬個用戶持續訪問，或是并發幾千訪問。

提問：一個是單個用戶、一個是批量用戶，他們之間產生的信息有差異性么。
Jason：這些信息都是類似的，每個請求都是一個HTTP請求，這肯定都是一樣的。但是數據呈現的東西不一樣。基調呈現的是從監控角度呈現，壓力是看負載、錯誤的統計，做這方面的。

提問：如果用壓測寶必須貴公司技術支持，還是我們本公司的測試也可以使用你們的環境？
Jason：你們可以使用這個環境，這個環境本來就是給大家來用的，但是這里面我們參與什么？一般會幫助做腳本錄制，錄下來還好辦，更多的對一些變量的調整。壓力測試的時候，我們準備最簡單的測試實際用戶，交給你之后，你可以拿出一萬個用戶，用戶名、帳號密碼這些信息肯定不能每個去做，通過一些規則、變量的方式去做，這種東西需要做腳本編寫。壓測寶提供了一些功能，但是是需要花一些時間研究和學習的。很多是我們幫著做的，做完以后照著這個就學會了。

提問：壓測報表是通過什么做的？
Jason：其實都是圖表呈現的插件，在創建壓力測試任務的時候，我們提供了大概幾十種數據呈現的選項，選擇完之后就會把圖形顯示出來。

轉載于:https://blog.51cto.com/9566716/1717320

總結

以上是生活随笔為你收集整理的《使用云计算和大数据进行性能测试》的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。