前言

這個效能測試真的感覺做了好久，一直都沒有一個好的結果。

為什麼要記錄，因為想讓自己以後不再犯類似錯誤！

要知道的幾個知識點

你看完，肯定會感謝我的，建議收藏！

關於系統支援併發數計算：

1、使用系統使用者數量*(5%~20%)：

比如使用者數為200人，平均取最大使用者數為80使用者左右，參考維基百科，可以自行查詢

2、按照經典公式計算：

平均每天大約200人使用系統8小時，從登入到退出平均時間為4小時，那麼

平均併發使用者數為：C = 2004/8 = 100
併發使用者數峰值為：C‘ = 100 + 3根號100 =130

參考自網路，感興趣自己去查即可。

關於測試策略調整

• 連線及相應超時設定為3分鐘
• submit
  與save取樣器之間間隔30秒
• 取消設定KeepAlive

測試過程

因為測試結果一直很不理想，導致整體進度很慢，多方嘗試，現把嘗試方案及測試過程記錄如下，以便他人蔘考和自己學習記錄，嘗試方案如下：

1、客戶端設定keep-alive，預設連線、響應超時，單服務

得出結論：

經常出現數據庫死鎖、service not started，頁面無法登陸

2、客戶端設定keep-alive，預設連線、響應超時設定3分鐘，單服務

經常出現數據庫死鎖、service not started，頁面無法登陸

3、客戶端取消設定keep-alive，預設連線、響應超時設定3分鐘，submit與save取樣器間隔1分鐘，3服務

0報錯，吞吐量6.1/sec，成功率100%。

4、客戶端取消設定keep-alive，預設連線、響應超時設定3分鐘，submit與save取樣器間隔1分鐘，單服務

0報錯，吞吐量5.5/sec，成功率100%。

整個過程很曲折，好在遇到比較有耐心和超強的技術解決問題，也讓我在這次測試中學習很多。

總結：

關於Keep-Alive設定對結果影響：

1. 設定Keep-Alive可以避免連線建立和釋放的開銷，但Tcp連線容易導致系統資源無效佔用，浪費系統資源。
2. 去掉 KeepAlive可以模擬多使用者訪問時每次請求是從不同源端新建請求連線，能更有效模擬真實測試壓力，適用於真實使用者直接訪問的服務介面和頁面壓測。
3. 在HTTP 1.1版本後，預設開啟Keep-Alive模式，可以加入 Connection: close才關閉連線，當然也可以設定Keep-Alive模式的屬性，例如 Keep-Alive: timeout=5, max=100，表示這個TCP通道可以保持5秒，max=100，表示這個長連線最多接收100次請求就斷開。（來自網路參考）