在這裏要強調一下，性能測試不是用Jemter和Loadrunner等工具，模擬幾個用戶跑個場景，再導出個測試報告，然後出去跟人家說我會壓力測試。這是丟人的，人家都笑話你。 完整的壓測流程：業務場景->性能指標->測試策略->性能腳本->分析系統->問題定位->性能報告。話題跑偏了，言歸正傳，今天的話題是【壓力測試瓶頸分析】，服務端出現性能瓶頸，分析思路如何展開。一、壓測目的
觀察系統的負載能力，測試系統在高負載的情況下的穩定性，評估系統當前的性能情況，解決性能的瓶頸。
二、服務端常見問題
CPU性能瓶頸有兩種情況：
CPU高、TPS低和CPU低、TPS也低
有同學問：“不是還有CPU低，TPS高的情況嗎”，這個情況不就是CPU沒有壓力，性能達標唄。
分析過程：
先定位進程->查看哪個進程使用率較高，找到被測服務的進程號->分析進程中，資源使用率高的線程->導出對應的線程日誌，進程定位具體的原因。
思路圖
內存性能瓶頸表現爲兩種：
內存泄露和內存溢出
引起內存泄露和溢出的原因如下：
分析內存的過程：
查看內存資源->判斷Gc的回收是否異常->導出內存日誌->分析具體的泄露對象。
常見的分析工具：MAT、profile、ha456.jar
思路圖
注意
大多數的中小型公司，對於性能的要求偏低，甚至不要求性能。這類公司大多業務形態散，迭代較快、市場佔有率低。即使遇到性能問題，不願意花費時間和人力成本，進行性能調優。一般通過加服務解決問題，對應了那句“通過錢能解決的事都不是事”。建議大家挑選性能相關工作，一定要找大廠，一定要找大廠，一定要找大廠。大廠讓你施展才華的機會纔會更多。
總結
1、性能調優和性能定位的原則，每次只改一處。改完後進行迴歸，如沒有解決問題，回滾到修改前，再次尋找可能出現的問題點進行優化再回歸
2、性能問題跟很多的因素有關，問題可能出現在任何節點，可能是程序，可能是中間件，也可能是配置的原因。所以在定位問題的時候，一定要熟悉數據的流轉，這樣你在排查問題的時候，腦子才能保持清醒。