支付寶的性能測試

　　一、性能測試支付寶場景介紹

　　2013年雙11過程當中，促銷開啟的第一分鐘內支付寶的交易總額就突破了一億元，短時間內大量用戶涌入的情況下，如何保證用戶的支付順暢，是對支付寶應用系統的一個極大的挑戰。

　　支付寶的性能測試場景分為性能基線測試，項目性能測試。

　　任意一筆交易過來，我們都需要對交易進行風險掃描，對于有可能是賬戶盜用的交易，我們會把這筆支付直接拒絕掉，或者通過手機校驗碼等方式進行風險釋放。

　　我們有一個老的掃描平臺A，現在需要構建一個新的掃描平臺B，對A中關鍵技術進行升級，并增加額外的功能。掃描的策略是存儲在DB中的，需要通過發布來更新到應用服務器的內存中。

　　二、性能測試需求分析和方案制定

　　a. 需求挖掘

　　1),查看業務方的顯性需求。業務方給到的需求為平臺B的分析性能要優于平臺A的性能。除此之外無其它的需求。

　　2),挖掘隱性需求.了解業務架構，了解業務流程。為了保證掃描的性能，大量的存儲類的需求被設計為異步處理，但是結果類的掃描需要使用到前面落地的數據，那么在系統正常運行時是否會存在落地數據讀取不到的問題，在存儲抖動時是否會導致后續的分析掃描全部失效?

　　首先我們通過運維監控平臺拿到平臺A的分析性能，RT<130ms, TPS>35.

　　基于以上的需求挖掘，我們確認的性能測試場景為

　　掃描性能場景。(單場景)

　　發布性能場景。(單場景)

　　掃描過程中發布性能場景。(混合場景)

　　b. 技術方案

　　1).評估我們的系統架構，系統調到鏈路，定位可能存在問題的瓶頸點。

　　2).掌握詳細技術實現方案，了解具體技術方案可能存在的性能問題。

　　比如我們是否使用到了腳本動態編譯，是Java腳本還是groovy腳本。是否使用到了線程池等異步處理，系統冪等性是如何控制的，數據結構是如何存儲與讀取的，是決策樹還是圖型結構。

　　3).了解系統環境的差異，比如服務器位數、CPU、內存的差異，JDK版本及位數的差異。

　　基于以上的技術方案，我們確認了上述3個性能測試場景可能存在的性能問題

　　1. 掃描性能場景

　　技術方案為掃描引擎drools2升級到了drools5.

　　性能關注點為請求掃描RT，TPS是否滿足我們的需求;JVM Old區內存溢出，Old區內存泄露;GC 頻率過高。CPU使用率，load.

　　2. 發布性能場景

　　技術方案為規則DB撈取->規則加載->規則引擎切換->規則腳本編譯。

　　性能關注點為CPU使用率,load。JVM Perm區內存溢出，Perm區內存泄露，GC 頻率過高。GC 暫停應用時間。

　　3. 掃描過程中發布性能場景。

　　性能關注點為請求掃描RT，TPS。規則發布耗時，CPU使用率，load, JVM GC頻率。

　　c. 性能測試方案制訂

　　分布式壓測，參數自動化，使用單元測試腳本，接口測試腳本，jmeter腳本等進行壓測。

　　性能結果收集及統計。

　　性能測試通過標準。

　　基于以上的分析

　　1. 掃描性能場景

　　性能測試方案：

　　使用jmeter 腳本進行分布式壓測，一臺master, 三臺slaver. 參數自動構建，使用高斯定時器模擬真實場景。

　　使用jmeter 收集分析性能數據，使用nmon收集服務器性能數據，使用jconsole收集JVM數據。

　　通過標準:

　　RT<130ms, TPS>35.

　　JVM old 區內無內存泄露，無內存溢出。GC時間間隔>30min，暫停應用時間<150ms.

　　CPU<70%， load < core*1.5。

　　2. 發布性能場景

　　性能測試方案：

　　發布時間間隔時間限制從1min調整為3s, 更快的暴露問題。

　　使用單元測試類推送發布消息。

　　服務器shell 腳本收集發布模塊性能數據。

　　使用nmon收集服務器性能數據。

　　使用jconsole收集JVM數據。

　　通過標準：

原文轉自：http://www.anti-gravitydesign.com