[性能調優]：記錄最近一次性能測試項目測試過程

 測試的系統是新上線的系統，爲中心繫統，對接各種外圍系統，預計會員數據在百萬級別，此處以「註冊」「登陸」兩個接口舉例說明在性能測試過程當中碰到的問題，以及解決問題的過程。

一，舉例的兩個接口很簡單，爲公司系統的手機註冊和登陸交易：

註冊流程爲：

　　1，客戶端申請手機驗證碼

　　2，服務器生成短信驗證碼後調用短信平臺發送短信

　　3，收取短信，提交註冊請求

　　4，服務器驗證請求

說明兩點狀況：

1‘，客戶端發送給服務器端的信息，先在本地經過三重加密（將json字符串用DES算法加密，加密後用base64編碼，發送請求時參數須要UrlEncoder編碼） ----------關於加密問題，另起一篇文章講述；

2’  此處程序版本爲性能測試作了點調整，服務器端，只生成驗證碼後返回給請求客戶端，不調用短信息平臺發送驗證碼。

2、腳本開發過程當中遇到的問題

因採用loadrunner11進行的腳本開發，LR11只支持32位的jdk版本，且對jdk的版本兼容性很差，若是採用開發JAVA Vuer類型的腳本，調用封裝好的jar包，測須要用一樣版本的jdk；

嘗試過在腳本中直接調用C語言程序的加密代碼，但每次的加密過程都須要編譯，耗時太長，沒法測試；

本次腳本開發過程當中，加密的程序是在本地運行，經過http協議訪問localhost，經過這種方式，避免了lr不能調用64位jar包的尷尬；

3、壓測及調優過程

因本次壓測的系統還未上線，因此採用峯值壓測方式，看看系統能處理的最大併發能力。

1，註冊交易，剛開始採用100用戶併發，總會有部分交易報錯（10%左右），當採用20用戶併發時候，不會報錯，成功率爲100%，

　問題緣由：推測鏈接池參數有關；

　優化方式：修改鏈接池參數，解決這個問題；

2，初次壓測註冊交易，監控到數據庫磁盤繁忙度和CPU使用率高，應用服務器CPU超閾值；

    問題緣由：經過MYSQL監控，監控到其中一條SQL語句在50秒執行了43000次，而實際的請求事務數，不到7000筆

 

優化方式，；sql語句程序邏輯上的優化，減小查詢次數

3，增長硬件資源後，發現cpu使用率最高爲50%，響應時間隨着併發數增長而增長，服務器的處理能力並未提高，監控後臺日誌發現發現提交註冊請求超時，超8秒以上，後臺日誌發現註冊完成後寫數據庫很慢，調整數據庫鏈接數20變爲100，速度由5秒變爲1秒之內

調整前：

調整後：

4，調整數據庫鏈接數後，，發現註冊激活業態信息很慢，開發須要從註冊的流程上進行優化

優化後結果：

平均時間由3秒多變爲0.1秒內

 可是發現LR測出來的結果依然不滿意，TPS和以前差不太多，服務器資源也負載不滿，思來想去，考慮到多是帶寬的問題（限制了上傳下載），

因此多增長一臺負載機壓測，發現帶寬下降爲一半，不是帶寬的瓶頸

遂考慮是否是在服務器處理請求（輸出第一條日誌）前，已經開始等待了，試着調整線程池參數，再來一次，陸續發現其餘的問題：

5，增長用戶數以後，事物響應時間也隨之成正比增長，TPS基本穩定在200左右；試着抓了一次資源信息，發現了一個磁盤的問題：

,

能夠看到保存數據信息，致使磁盤寫繁忙度達閾值，其實是由於這個數據庫服務器部署在虛擬機上，本省的磁盤讀寫速度就很慢，和環境組溝通後，從新申請了物理機，部署。調整後，看到磁盤讀寫能力大大提高了，以下圖：

提高速度已經很明顯了，果真發現TPS有必定幅度的提高，但仍是沒有達到目標，

6，後面的優化，實際上也沒有發現什麼問題：和開發溝通後，由於是註冊保存數據較慢，考慮到redis內存存儲信息，加快保存數據處理

採用redis存儲以後，壓測，好像依然沒有改善，後面分析超時日誌信息，發現問題在操做redis時計算分片的函數耗時較長

7，優化計算redis分片函數以後，性能直接提高到了1000了，

監控服務器數據，又發現一個問題：

數據庫中間件Mycat第一臺的網絡負載壓力較大，26M/秒，緣由是負載均衡問題，配置問題，小問題，修改後驗證。

至此，此次的測試算是達到目標了，測試任務完成了，

本次經驗總結：

1，環境準備：因本次測試的指標目標較高，對個方面資源的性能要求較高，在CPU、內存、磁盤、網絡，負載機，個方面準備須要提早；

例如負載機的問題，由於本次壓測數據吞吐量較高，若是沒有提早申請和服務器同一網段的負載機，後面進行壓測歷史的話，網絡就會限制，在同一網段的負載機上壓測，網絡問題就基本能夠忽略；

2，腳本開發：本次註冊的腳本，發送請求信息，在客戶端都有一個三重加密步驟：UrlEncoder.encode(Base64.encode(DES.encrypt(jsonStr, key)), "utf-8")；

加密的jar包須要開發提早提供；

其次，註冊須要發送手機驗證碼，在生產的版本，會對手機號格式校驗，以及發送真是短信到手機上，這樣在腳本中是跑不了的；

因此須要對程序版本進行必定的修改：1，不校驗手機號格式，2，不真實發送手機短信，短信驗證碼包含在申請驗證碼的返回報文信息中；

3，壓測調優過程：

1）200用戶併發時，部分交易報系統錯誤，調整線程池參數，增長線程池鏈接數；

2）數據庫慢查詢監控，將耗時較長的sql語句挑出來優化；

3）數據庫語句監控，例如監控到一次交易中，屢次反覆執行的sql語句，從代碼的執行邏輯上優化，減小sql語句執行次數，較少代碼開銷

4）監控硬件資源，在硬件資源產生瓶頸以後，提高內存和CPU的資源；

5）增長用戶併發數，提升服務器日誌級別，將耗時較長的交易流水找出來，逐條分析日誌，定位耗時較長的函數，發現保存用戶註冊信息較慢，優化數據庫鏈接數參數；

6）本來爲了方便，是用本地負載機作的壓測，當網絡傳輸數據量到達必定時，本地負載機的網絡成了瓶頸，遂換到和測試環境同一網段的遠程機上作壓測；

7）繼續壓測，發現註冊保存用戶信息仍然較慢，監控到磁盤繁忙度較高，瞭解到測試環境數據庫部署到的虛擬機上時，處理能力較差，遂申請更換物理服務器，提升磁盤讀寫能力；

8）到硬盤讀寫能力和網絡能力提高以後，處理能力並沒有本質提高，開發考慮纔有redis內存保存的方式，提升存儲速度，壓測後略微有提高；

9）監控後發現，在寫redis內存塊，處理速度較慢，分析爲操做redis時計算分片的函數耗時較長

10）監控數據庫中間件Mycat網絡負載不均衡，參數設置問題；

 

 

以上。