性能調優的方法有哪些

本篇內容介紹了“性能調優的方法有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

1.性能測試是什么

性能測試就是通過特定的方式，對被測系統按照一定的測試策略施加壓力，獲取該系統的響應時間、吞吐量、資源利用率等性能指標，來檢驗系統上線后能否滿足用戶需求的過程，主要包括測試需求/目的、測試環境/工具、測試方案、測試執行、測試結果與分析。

2.衡量系統的四大指標

衡量一個系統的性能，主要有以下四大指標：

響應時間

指應用執行一個操作所需的時間，包括從發出請求開始到最后收到響應所需要的時間。響應時間是系統最重要的性能指標，直觀的反映了系統的快慢。

吞吐量

指單位時間內系統處理的請求數，體現系統的整體處理能力。TPS(Transaction per second)是吞吐量的一個常用量化指標，此外還有HPS(Hits per second)、QPS(Query per second)等。

資源利用率

指應用服務器、數據庫服務器及被測系統包含的中間件服務器的CPU、內存、磁盤、網絡等系統資源的使用情況。

并發數

指的是同時提交請求的用戶數目。這四個指標之間的關系如圖1。

圖2

一個請求從發出到接收響應，如圖2所示。大致流程如下：

1. 客戶端發送請求報文。客戶端發送請求報文，經過網絡傳輸后到達服務端；

2. 服務端處理。服務端接收到請求報文后，進行業務邏輯處理和必要的數據讀寫操作；

3. 服務端返回響應報文。服務端處理完后，將響應報文發送到客戶端。

我們通常說的響應時間是第1步、第2步、第3步消耗的總時間。第1步主要是客戶端請求耗時和網絡耗時；第2步主要是業務邏輯、數據讀寫和網絡耗時；第3步主要是客戶端渲染和網絡耗時。

第1、2、3步每一步都有可能存在性能問題，導致響應時間變長。第1步中如客戶端主機配置低，反應慢等，第二步中如業務線程阻塞、數據庫查詢慢；第3步中如網絡傳輸延遲。根據各種問題的類型，我們又可以把問題歸為硬件問題、網絡問題、代碼問題、中間件問題等。不同問題也有不同的調優方法，下面我們簡單聊一聊性能調優。

4.抓住時間的小偷-性能調優

常用的調優方法有：

• 空間換時間。如數據緩存，提前從磁盤上讀取數據緩存到內存中，CPU請求數據直接從內存中獲取，從而達到更高的效率；

• 時間換空間，如上傳大附件，將數據分批次處理，用更少的空間完成任務處理；

• 分而治之，把任務切分，分開執行，也方便并行執行來提高效率；

• 異步處理，如互聯網應用最常見的MQ消息隊列，將業務鏈路上比較耗時的業務拆分出來，通過異步處理減少阻塞影響；

• 并行，多個進程或者線程同時處理業務，縮短業務處理時間；

• 離用戶更近一點，如CDN技術，把用戶請求的靜態資源放在離用戶更近的地方；

• 一切可擴展，業務模塊化、服務化（同時無狀態化）、良好的水平擴展能力。

下面我們舉幾個案例進行說明。

案例1

問題描述： 壓測某接口時，隨著壓測執行，響應時間越來越長。

問題分析：

1. 打印線程堆棧，對比線程堆棧信息，發現線程堆棧中FailoverEvent的線程數越來越多，最終內存溢出；

2. 查看代碼發現，程序中未判斷FailoverEvent線程隊列是否已經存在，導致FailoverEvent線程隊列重復創建。

解決方案：調用下游服務改用多線程方式。

解決方案：去掉冗余調用，一次請求調用一次selectList方法。

解決方案 ：將事務1拆分，先查詢，然后根據查詢的結果批量刪除。

優化結果 ：死鎖問題解決。

調優建議 ：

1. 避免大事務；

2. 按同一順序訪問數據對；

3. 避免編寫包含用戶交互的事務；

4. 酌情使用低隔離級別，如RC；

5. 為表添加合理的索引，如果不走索引將會為表的每一行記錄加鎖，死鎖的概率就會大大增大；

6. 避免在同一時間點運行多個對同一表進行讀寫的腳本，特別注意加鎖且操作數據量比較大的語句；

7. 設置鎖等待超時參數，innodb_lock_wait_timeout。

5.總結

響應時間通常只是問題的表現，根本原因在于各種資源的利用是否合理，這里的資源是指廣義的資源，包括硬件/軟件資源、系統/線程/數據等不同級別的資源。調優本身，就是對各種資源進行更合理的配置。調優的目的通常也是為了滿足業務需求，因此我們不必追求過早和過度優化，并且我們應該認識到，性能調優不可能一勞永逸，隨著業務的迭代，總會有新的問題出現，因此我們應該具備打持久戰的共識和能力。

“性能調優的方法有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！