性能測試，是結合被測系統應用架構、業務場景和實現細節、邏輯，對軟件響應時間、處理速率、容錯能力等進行分析測試，找到系統的性能瓶頸，並確認問題得到解決的過程。
由於工作需要，對性能測試缺陷分類進行了整理，這篇博客，聊聊常見的性能缺陷以及表現方式。。。
性能測試缺陷分類
| 缺陷類型 | 缺陷描述 |
| 硬件 | 磁盤空間 |
| CPU | |
| IO讀寫速率 | |
| 內存 | |
| 網絡 | 帶寬 |
| 網絡波動 | |
| CDN | |
| 延時 | |
| 丟包 | |
| 應用 | JVM |
| 代碼邏輯 | |
| 配置 | JDK版本 |
| 底層配置 | |
| 參數配置 | |
| 數據庫 | 索引 |
| 鎖 | |
| 表空間 | |
| 慢SQL | |
| 數據量 | |
| 中間件 | 超時 |
| 線程池 | |
| 緩存策略 | |
| 最大連接數 | |
| 通信實現方式 | |
| 負載均衡 |
一、硬件
磁盤空間：磁盤空間不足導致系統運行變慢，文件、日志等無法生成存放導致的性能瓶頸；
CPU：CPU的核心功能是解釋計算機指令以及處理數據，性能主要體現在其運行程序的速度上。影響運行速度的性能指標包括工作頻率、Cache容量、指令系統和邏輯結構等參數；
IO讀寫速率：即input和output，輸入和輸出，主要考慮數據處理時的讀寫速度，頁交換等情況；
內存：所有的程序都是運行在內存中的，其作用是用於暫時存放CPU中的運算數據，以及與外部存儲器交換的數據，內存不足會限制程序的數據處理速度，因此這也是很重要的一項性能關注指標；
二、網絡
帶寬：高並發情況下，如果帶寬不足，可能會導致網絡資源競爭，超時等情況；
網絡波動：這里是從網絡的穩定性來描述，即性能測試的環境，需要一個穩定的網絡環境；
CDN：即內容分發服務，有時候不同的CDN策略也會影響到“用戶”感知到的系統性能表現；
延時：延時的值越大，對系統性能表現影響越大（比如格斗類的PVP游戲），且性能測試的結果也存在更大的偏差；
丟包：數據在網絡上是以數據包的形式傳輸的，如果丟包，則可能造成報錯或異常的情況；
三、應用
1、JVM
堆內存分配：根據系統硬件條件來進行合理的堆內存分配，一般來說JVM的堆內存分配不要超過系統內存的25%較好；
垃圾回收算法：JAVA的動態垃圾回收機制，是基於不同的幾種回收算法來進行的，根據具體的情況，選擇合適的垃圾回收策略；
OOM：即內存溢出（out of memory），這個算是性能測試中很常見的一個問題，通常是由於代碼問題造成的內存泄漏、GC不夠徹底、內存被耗盡引起；
2、代碼邏輯
常見的情況有不合理的線程引用和內存分配；
四、配置
版本：在性能測試過程中，一定要確保被測系統的版本和實際生產保持一致，否則由於版本不同帶來的些許差異可能會對性能測試帶來很大的偏差和影響；
底層配置：涉及到操作系統、服務器等硬件的一些配置方式不合理，帶來的性能瓶頸；
參數配置：系統架構設計中，各個不同的參數配置帶來的性能瓶頸；
五、數據庫
索引：索引的存在就像一個標簽目錄一樣，在執行數據庫操作時提供更為快速的執行效率，減少磁盤IO操作和執行的數據庫系統時間；
鎖：為了保證事務的原子性和隔離性，有了鎖的存在，但有時候由於某些原因造成的表鎖，也是性能瓶頸的一種表現；
表空間：不合理的表空間設計，導致的數據庫性能問題；
慢SQL：慢SQL會導致數據庫操作時間變長，增加IO讀寫以及引起一些列的資源競爭等問題，常見的慢SQL原因如下（以MySQL為例）：
數據量：對同一張表來說，1W條數據和1000W條數據，對其進行操作時的性能表現也是不同的，因此在性能測試時對於數據的正確性可用性，以及數據量也是需要重點關注的；
六、中間件
超時：設置合理的請求或響應超時時間，是很有必要的，這點要根據具體的業務場景和系統架構來考慮，具體的超時時間，建議進行配置測試來設定；
線程池：之前的博客介紹過線程池的相關資料，線程池配置太小，很容易被使用完，太大的話又浪費資源，合理的線程池，建議進行配置測試來確定；
緩存策略：緩存的優點是減少請求響應過程中的傳輸時間，但有時候在高並發情況下，緩存很容易失效而導致緩存穿透，瞬間對服務端帶來很大的壓力；
最大連接數：關於連接數，之前的博客也介紹過，合理的連接數配置是很重要的，否則連接數太少容易導致隊列等待、超時，連接數太多則浪費了系統資源；
通信實現方式：同步（sync）和異步（Async）；
負載均衡策略：現在很多的系統都進行了服務集群，隨之而來的就是負載均衡策略的實現，如果負載均衡不夠“均衡”，在大數量的沖擊下，容易導致某些服務的異常或者掛起；
以上內容為整理出的常見的影響系統應用性能表現的常見缺陷，更詳細的內容比如實現原理、處理邏輯等請自行查閱其他資料，內容僅供參考。。。