分析流程：
很多情況下壓測流量並沒有完全進入到后端（服務端），在網絡接入層（雲化的架構比如：SLB/WAF/高防IP，甚至是CDN/全站加速等）可能就會出現由於各種規格（帶寬、最大連接數、新建連接數等）限制或者因為壓測的某些特征符合CC和DDoS的行為而觸發了防護策略導致壓測結果達不到預期。
分析關鍵指標是否滿足要求，如果不滿足，需要確定是哪個地方有問題，一般情況下，服務器端問題可能性比較大，也有可能是客戶端問題（這種情況非常小）。
對於服務器端問題，需要定位的是硬件相關指標，例如CPU，Memory, Disk I/O, Network I/O, 如果是某個硬件指標有問題，需要深入的進行分析。
如果硬件指標都沒有問題，需要查看中間件相關指標，例如：線程池、連接池、GC等，如果是這些指標問題，需要深入的 分析。
如果中間件相關指標沒問題，需要查看數據庫相關指標，例如：慢查SQL，命中率，鎖、參數設置。
如果以上指標都正常，應用程序的算法、緩沖、緩存、同步或異步可能有問題，需要具體深入的分析。

可能存在的瓶頸點及優化思路
硬件瓶頸：
一般指的是CPU、內存、磁盤I/O 方面的問題，分為服務器硬件瓶頸、網絡瓶頸
中間件性能瓶頸：
web軟件，數據庫，緩存等
應用程序瓶頸：
JVM參數不合理，容器配置不合理，慢SQL，慢事務，數據庫設計不合理，程序架構規划不合理，程序本身設計有問題（串行處理、請求的處理線程不夠、無緩沖、無緩存、生產者和消費者不協調等），造成系統在大量用戶方位時性能低下而造成的瓶頸。
操作系統瓶頸：
連接數，虛擬內存，內核參數等
網絡設備瓶頸：
包括但不限於SLB/WAF/高防IP/CDN/全站加速等
瓶頸應對手段
CPU：
如果CPU User非常高，需要查看消耗在哪個進程，可以用top(linux)命令看出，接着用top –H –p
如果CPU Sys非常高，可以用strace(linux)看系統調用的資源消耗及時間；
如果CPU Wait非常高，考慮磁盤讀寫，可以通過減少日志輸出、異步或換速度快的硬盤。
內存：
內存的問題主要看某個進程占用的內存是否非常大以及是否有大量的swap(虛擬內存交換)。
磁盤IO：
磁盤I/O一個最顯著的指標是繁忙率，可以通過減少日志輸出、異步或換速度快的硬盤。
網絡IO：
網絡I/O主要考慮傳輸內容大小，不能超過硬件網絡傳輸的最大值70%，可以通過壓縮、減少內容大小、在本地設置緩存以及分多次傳輸等。
內核參數：
注意運行參數不要超過內核參數而導致系統出現問題
JVM：
jvm主要分析GC/FULL GC是否頻繁，以及垃圾回收的時間，可以用jstat命令來查看，對於每個代大小以及GC頻繁，通過jmap將內存dump,再借助工具HeapAnalyzer來分析哪地方占用的內存較高以及是否有內存泄漏可能。
線程池：
如果線程不夠用，可以通過參數調整，增加線程；對於線程池中的線程設置比較大的情況，還是不夠用可能的原因是：某個線程被阻塞來不及釋放，可能在等鎖、方法耗時較長、數據庫等待時間很長等原因導致，需要進一步分析才能定位。
JDBC連接池：
連接池不夠用的情況下，可以通過參數進行調整增加；但是對於數據庫本身處理很慢的情況下，調整沒有多大的效果，需要查看數據庫方面以及因代碼導致連接未釋放的原因。
SQL：
慢SQL，可以通過查看執行計划看SQL慢在哪里來進一步優化。