模板
教程
環境
性能
功能
管理
在高負載壓力下支付寶是如何做性能測試的(2)
通過標準:
RT<130ms, TPS>35.
JVM old 區內無內存泄露，無內存溢出。GC時間間隔>30min，暫停應用時間<150ms.
CPU<70%， load < core*1.5。
2. 發布性能場景
性能測試方案：
發布時間間隔時間限制從1min調整為3s, 更快的暴露問題。
使用單元測試類推送發布消息。
服務器shell 腳本收集發布模塊性能數據。
使用nmon收集服務器性能數據。
使用jconsole收集JVM數據。
通過標準：
JVM Perm 區內無內存泄露，無內存溢出。GC時間間隔>10min，暫停應用時間<200ms.
發布時間<30S
CPU<70%， load < core*1.5。
3.掃描過程中發布性能場景
性能測試方案：
使用jmeter腳本進行分布式壓測，同時提交發布請求進行發布。
同時使用掃描性能場景和發布性能場景收集數據功能。
通過標準：
RT < 掃描性能場景結果RT * 110%.
TPS > 掃描性能場景結果TPS * 90%.
發布時間 < 40s。
d. 發現的問題
1. 掃描性能場景
AVG RT = 473ms， CMS GC = 90ms, 應用暫停時間 = 1s, 因此測試未通過。
問題定位：
dump內存，使用ibm memory analyzer 分析。
確認cms gc的原因為drools引擎的finalize方法。Finzlize方法不能正確的釋放對象的引用關系，導致引用關系一直存在，無法釋放。
調優方案：
根據drools的升級文檔，升級drools引擎后解決此問題
2. 發布性能場景
CMS GC 回收失敗，內存無法被釋放，應用宕機。
問題定位：
GC回收比例為默認值68%，OLD區內存1024M，那么回收的臨界值為1024*0.68=696.32M。系統的JVM內存占用為500M，掃描策略相關的內存為120M，在切換的過程中，依賴額外的120M，因此只有在可用內存大于740M時才能正?；厥?。
解決方案：
調整JVM參數，擴大GC回收比例。
后續技術方案改造，使用增量發布解決此問題。
3. 掃描過程中發布性能場景
問題定位：
掃描平臺發布流程，當首次請求進來時執行腳本動態編譯過程，由于腳本較多，因此所有腳本的動態編譯時間較長，在此過程中，進來的所有請求都會被hand住，造成大量超時
解決方案：
把腳本的動態編譯提前到首次請求調用進來之前，編譯通過后再切換掃描引擎，保證首次請求進來前一切準備就緒。
三：性能測試的執行和結果收集
3.1性能測試的執行
性能測試的執行需要具備以下幾個條件：施壓工具,測試環境以及對測試結果的收集工具。
3.1.1 施壓工具
我們先來說說施壓工具，支付寶使用的主流施壓工具是開源工具Apache JMeter，支持很多類型的性能測試：
Web - HTTP, HTTPS
SOAP
Database via JDBC
LDAP
JMS
支付寶大部分接口是webservice接口，基于soap協議，且都是java開發，所以使用jmeter非常方便，即使jemter工具本身沒有自帶支持的協議，也可以通過開發插件的方式支持。
3.1.2測試環境
測試環境包括被壓機和施壓機環境，需要進行硬件配置和軟件版本確認，保證系統干凈，無其他進程干擾，最好能提前監控半小時到1小時，確認系統各項指標都無異常。
另外除了被壓機和施壓機，有可能應用系統還依賴其他的系統，所以我們需要明確服務器的數量和架構，1是方便我們分析壓力的流程，幫助后面定位和分析瓶頸，2是由于我們線下搭建的環境越接近線上，測試結果越準確。但是通常由于測試資源緊張或者需要依賴外圍，例如銀行的環境，就會比較麻煩，通常我們會選擇適當的進行環境mock。當然，Mock的時候盡量和真實環境保持一致，舉個簡單的例子，如果支付寶端系統和銀行進行通信，線上銀行的平均處理時間為 100ms，那么如果我們在線下性能測試時需要mock銀行的返回，需要加入100ms延遲，這樣才能比較接近真實的環境。
另外除了測試環境，還有依賴的測試數據也需要重點關注，數據需要關注總量和類型，例如支付寶做交易時，db中流水萬級和億級的性能肯定是不一樣的;還有db是否分庫分表，需要保證數據分布的均衡性。一般考慮到線下準備數據的時長，一般性能測試要求和線上的數據保持一個數量級。
原文轉自：http://www.infoq.com/cn/articles/performance-test-of-zhifubao
