性能測試結果分析思路

  問：併發用戶持續增加，TPS趨於水平，單位響應時間也相應變長，1、cpu、內存無大量佔用；2、網絡帶寬足夠；3、沒有出現失敗交易，可能有什麼原因。

思路：

那麼是什麼原因會導致“表象”是軟件的壓力頂點呢？
本身就是軟件處理能力極限，原因很多啊（這裏不考慮系統資源與帶寬）
（1）是不是架構的原因？比如某些架構裏面有些外圍系統性能導致你本身測試的系統反應不過來。（可以擋板一把再測試）
（2）是不是代碼原因？比如某些業務邏輯處理複雜，或者是異常處理拋錯，但研發人員將此拋錯捕獲，然後做一些異常finally的動作導致處理很慢，甚至調用一些系統內核的函數導致反覆翻頁（這個要研發人員優化代碼哦）
（3）是不是中間件配置原因？比如某些中間件的線程數不夠，你要監控線程數是不是達到你配置的最大值，同時等待時間，超時時間等要統一考慮。又或者是不是數據庫連接池的配置不對，其實基準測試的時候就該搞清楚嘛。
（4）是不是數據庫原因？。例如：數據庫某些存儲過程響應時間就很慢，或者說是相關表的索引字段建的對不對，是不是有全表掃描，請求鎖情況怎麼樣。緩存點擊率呢？某些表的數據超大，有木有分表機制哦。。。等等
（5）是不是其他原因，例如java虛擬機的內存達到頂峯，，又或者本身就是你壓力機的CPU滿了，哥你尷尬啦

（6） 哦代碼因素還有一個例子，就是說代碼中一些成熟的線程管理lib，也不一定都OK，多線程安全機制要根據實際情況來哦。 
這裏排除資源利用率（CPU，內存，磁盤IO等）與網絡因素