原創 侯龍
一個好的軟件，功能和性能都至關重要，這當然離不開產品同學的開光腦瓜、研發同學的靈巧小手，也離不開測試同學的金晶火眼。說到測試，可能大家就會想到頁面點點點呀，接口驗證呀，業務聯調呀等等，其實還有一個很重要的環節，那就是性能測試。
那麼，什麼是性能測試？如何衡量系統性能？系統響應時間是怎麼計算的？如何進行性能調優？帶着這些問題，咱們今天就來簡單地聊一聊性能調優那些事兒。
1.性能測試是什麼
性能測試就是通過特定的方式，對被測系統按照一定的測試策略施加壓力，獲取該系統的響應時間、吞吐量、資源利用率等性能指標，來檢驗系統上線後能否滿足用戶需求的過程，主要包括測試需求/目的、測試環境/工具、測試方案、測試執行、測試結果與分析。
2.衡量系統的四大指標
衡量一個系統的性能，主要有以下四大指標：
響應時間
指應用執行一個操作所需的時間，包括從發出請求開始到最後收到響應所需要的時間。響應時間是系統最重要的性能指標，直觀的反映了系統的快慢。
吞吐量
指單位時間內系統處理的請求數，體現系統的整體處理能力。TPS(Transaction per second)是吞吐量的一個常用量化指標，此外還有HPS(Hits per second)、QPS(Query per second)等。
資源利用率
指應用服務器、數據庫服務器及被測系統包含的中間件服務器的CPU、內存、磁盤、網絡等系統資源的使用情況。
併發數
指的是同時提交請求的用戶數目。這四個指標之間的關係如圖1。
圖1
吞吐量= 併發數/平均響應時間吞吐量= 併發數/平均響應時間。
從圖1我們可以看到：
-
當系統壓力較小時，響應時間幾乎無變化，吞吐量和系統資源隨併發數的增加呈線性增長趨勢；
-
當系統壓力較大時，隨着併發數增加，響應時間也逐漸增加，系統資源達到極限，吞吐量不再增長；
-
繼續增加併發數，響應時間快速增長，系統資源仍然在極限狀態，吞吐量迅速下降。
一般情況下，我們希望系統能夠支持更大的併發和更大的吞吐量。但是，從上面的分析我們可以看到，併發數的增長不會一直帶來吞吐量的增長，因爲系統資源使用率達到極限後，響應時間將會是決定吞吐量的更大因素，那麼，時間都去哪兒了呢？
3.時間都去哪兒了
圖2
一個請求從發出到接收響應，如圖2所示。大致流程如下：
-
客戶端發送請求報文。客戶端發送請求報文，經過網絡傳輸後到達服務端；
-
服務端處理。服務端接收到請求報文後，進行業務邏輯處理和必要的數據讀寫操作；
-
服務端返回響應報文。服務端處理完後，將響應報文發送到客戶端。
我們通常說的響應時間是第1步、第2步、第3步消耗的總時間。第1步主要是客戶端請求耗時和網絡耗時；第2步主要是業務邏輯、數據讀寫和網絡耗時；第3步主要是客戶端渲染和網絡耗時。
第1、2、3步每一步都有可能存在性能問題，導致響應時間變長。第1步中如客戶端主機配置低，反應慢等，第二步中如業務線程阻塞、數據庫查詢慢；第3步中如網絡傳輸延遲。根據各種問題的類型，我們又可以把問題歸爲硬件問題、網絡問題、代碼問題、中間件問題等。不同問題也有不同的調優方法，下面我們簡單聊一聊性能調優。
4.抓住時間的小偷-性能調優
常用的調優方法有：
-
空間換時間。如數據緩存，提前從磁盤上讀取數據緩存到內存中，CPU請求數據直接從內存中獲取，從而達到更高的效率；
-
時間換空間，如上傳大附件，將數據分批次處理，用更少的空間完成任務處理；
-
分而治之，把任務切分，分開執行，也方便並行執行來提高效率；
-
異步處理，如互聯網應用最常見的MQ消息隊列，將業務鏈路上比較耗時的業務拆分出來，通過異步處理減少阻塞影響；
-
並行，多個進程或者線程同時處理業務，縮短業務處理時間；
-
離用戶更近一點，如CDN技術，把用戶請求的靜態資源放在離用戶更近的地方；
-
一切可擴展，業務模塊化、服務化（同時無狀態化）、良好的水平擴展能力。
下面我們舉幾個案例進行說明。
案例1
問題描述： 壓測某接口時，隨着壓測執行，響應時間越來越長。
問題分析：
-
打印線程堆棧，對比線程堆棧信息，發現線程堆棧中FailoverEvent的線程數越來越多，最終內存溢出；
-
查看代碼發現，程序中未判斷FailoverEvent線程隊列是否已經存在，導致FailoverEvent線程隊列重複創建。
解決方案：創建FailoverEvent線程隊列前，判斷其是否存在，如果不存在則創建，如果存在，則使用現有對象。
優化結果：內存溢出問題解決，響應時間正常。
調優建議：
-
儘早釋放無用對象的引用；
-
程序進行字符串處理時，儘量避免使用String，而應使用StringBuffer；
-
儘量少用靜態變量；
-
避免集中創建對象尤其是大對象；
-
儘量運用對象池技術以提高系統性能；
-
不要在經常調用的方法中創建對象，尤其是忌諱在循環中創建對象。
案例2
問題描述： 某批量處理接口，無積壓的情況下，10000訂單，4500sku種類處理時間耗時433秒。
問題分析： 接口中採用單線程方式調用下游服務，查詢次數=sku種類數/11，4500sku種類約410次，且每次調用耗時約519ms。
解決方案：調用下游服務改用多線程方式。
優化結果：TP99由212秒下降到33秒，TPS由87筆/秒提升到127筆/秒。
調優建議：本案例採用多線程降低了響應時間，但並不是說多線程一定比單線程快，因爲幹活的是CPU，不是線程。我們可以通過確認系統有無磁盤/網絡IO來進行選擇，有，多線程；無，單線程。並且採用多線程時，一定要使用線程池。
案例3
問題描述： 數據查詢接口，TP99=727ms，加大併發，吞吐量無法提升，應用服務器CPU使用率始終不到40%。
問題分析： 通過調用鏈分析我們發現，一次請求，調用了11次selectList方法，導致接口總耗時飆升。
解決方案：去掉冗餘調用，一次請求調用一次selectList方法。
優化結果：TP99由727ms下降到19ms，提升38倍，TPS由17.5筆/秒提升至163.4筆/秒，提升9倍。
調優建議：
-
設計先於代碼；
-
基本原則：把數據庫操作放在循環之外；
-
如果是查詢，使用IN查詢替換for循環(空間換時間)；
-
如果是新增，使用批量插入。
案例4
問題描述： 某接口提交數據庫操作，更新數據時產生死鎖。
問題分析： 產生死鎖的事務如表1：
解決方案 ：將事務1拆分，先查詢，然後根據查詢的結果批量刪除。
優化結果 ：死鎖問題解決。
調優建議 ：
-
避免大事務；
-
按同一順序訪問數據對；
-
避免編寫包含用戶交互的事務；
-
酌情使用低隔離級別，如RC；
-
爲表添加合理的索引，如果不走索引將會爲表的每一行記錄加鎖，死鎖的概率就會大大增大；
-
避免在同一時間點運行多個對同一表進行讀寫的腳本，特別注意加鎖且操作數據量比較大的語句；
-
設置鎖等待超時參數，innodb_lock_wait_timeout。
5.總結
響應時間通常只是問題的表現，根本原因在於各種資源的利用是否合理，這裏的資源是指廣義的資源，包括硬件/軟件資源、系統/線程/數據等不同級別的資源。調優本身，就是對各種資源進行更合理的配置。調優的目的通常也是爲了滿足業務需求，因此我們不必追求過早和過度優化，並且我們應該認識到，性能調優不可能一勞永逸，隨着業務的迭代，總會有新的問題出現，因此我們應該具備打持久戰的共識和能力。
推薦閱讀
歡迎點擊【京東科技】，瞭解開發者社區
更多精彩技術實踐與獨家乾貨解析
歡迎關注【京東科技開發者】公衆號
