性能測試：常見的性能測試缺陷

性能測試，是結合被測系統應用架構、業務場景和實現細節、邏輯，對軟件響應時間、處理速率、容錯能力等進行分析測試，找到系統的性能瓶頸，並確認問題獲得解決的過程。html

因爲工做須要，對性能測試缺陷分類進行了整理，這篇博客，聊聊常見的性能缺陷以及表現方式。。。算法

性能測試缺陷分類數據庫

1、硬件緩存

磁盤空間：磁盤空間不足致使系統運行變慢，文件、日誌等沒法生成存放致使的性能瓶頸；服務器

CPU：CPU的核心功能是解釋計算機指令以及處理數據，性能主要體如今其運行程序的速度上。影響運行速度的性能指標包括工做頻率、Cache容量、指令系統和邏輯結構等參數；網絡

IO讀寫速率：即input和output，輸入和輸出，主要考慮數據處理時的讀寫速度，頁交換等狀況；架構

內存：全部的程序都是運行在內存中的，其做用是用於暫時存放CPU中的運算數據，以及與外部存儲器交換的數據，內存不足會限制程序的數據處理速度，所以這也是很重要的一項性能關注指標；併發

2、網絡負載均衡

帶寬：高併發狀況下，若是帶寬不足，可能會致使網絡資源競爭，超時等狀況；異步

網絡波動：這裏是從網絡的穩定性來描述，即性能測試的環境，須要一個穩定的網絡環境；

CDN：即內容分發服務，有時候不一樣的CDN策略也會影響到「用戶」感知到的系統性能表現；

延時：延時的值越大，對系統性能表現影響越大（好比格鬥類的PVP遊戲），且性能測試的結果也存在更大的誤差；

丟包：數據在網絡上是以數據包的形式傳輸的，若是丟包，則可能形成報錯或異常的狀況；

3、應用

一、JVM

堆內存分配：根據系統硬件條件來進行合理的堆內存分配，通常來講JVM的堆內存分配不要超過系統內存的25%較好；

垃圾回收算法：JAVA的動態垃圾回收機制，是基於不一樣的幾種回收算法來進行的，根據具體的狀況，選擇合適的垃圾回收策略；

OOM：即內存溢出（out of memory），這個算是性能測試中很常見的一個問題，一般是因爲代碼問題形成的內存泄漏、GC不夠完全、內存被耗盡引發；

二、代碼邏輯

常見的狀況有不合理的線程引用和內存分配；

4、配置

版本：在性能測試過程當中，必定要確保被測系統的版本和實際生產保持一致，不然因爲版本不一樣帶來的些許差別可能會對性能測試帶來很大的誤差和影響；

底層配置：涉及到操做系統、服務器等硬件的一些配置方式不合理，帶來的性能瓶頸；

參數配置：系統架構設計中，各個不一樣的參數配置帶來的性能瓶頸；

5、數據庫

索引：索引的存在就像一個標籤目錄同樣，在執行數據庫操做時提供更爲快速的執行效率，減小磁盤IO操做和執行的數據庫系統時間；

鎖：爲了保證事務的原子性和隔離性，有了鎖的存在，但有時候因爲某些緣由形成的表鎖，也是性能瓶頸的一種表現；

表空間：不合理的表空間設計，致使的數據庫性能問題；

慢SQL：慢SQL會致使數據庫操做時間變長，增長IO讀寫以及引發一些列的資源競爭等問題，常見的慢SQL緣由以下（以MySQL爲例）：

數據量：對同一張表來講，1W條數據和1000W條數據，對其進行操做時的性能表現也是不一樣的，所以在性能測試時對於數據的正確性可用性，以及數據量也是須要重點關注的；

6、中間件

超時：設置合理的請求或響應超時時間，是頗有必要的，這點要根據具體的業務場景和系統架構來考慮，具體的超時時間，建議進行配置測試來設定；

線程池：以前的博客介紹過線程池的相關資料，線程池配置過小，很容易被使用完，太大的話又浪費資源，合理的線程池，建議進行配置測試來肯定；

緩存策略：緩存的優勢是減小請求響應過程當中的傳輸時間，但有時候在高併發狀況下，緩存很容易失效而致使緩存穿透，瞬間對服務端帶來很大的壓力；

最大鏈接數：關於鏈接數，以前的博客也介紹過，合理的鏈接數配置是很重要的，不然鏈接數太少容易致使隊列等待、超時，鏈接數太多則浪費了系統資源；

通訊實現方式：同步（sync）和異步（Async）；

負載均衡策略：如今不少的系統都進行了服務集羣，隨之而來的就是負載均衡策略的實現，若是負載均衡不夠「均衡」，在大數量的衝擊下，容易致使某些服務的異常或者掛起；

以上內容爲整理出的常見的影響系統應用性能表現的常見缺陷，更詳細的內容好比實現原理、處理邏輯等請自行查閱其餘資料，內容僅供參考。。。