JMeter JDBC數據庫測試 - 最大等待時間（ms）

Question

JDBC連接配置中Max Wait（ms）值的最佳做法是什麼？ JDBC

我執行2種類型的測試：

1. 20環線程的每個號碼 - 以獲得最大的Throupught
2. 30分鐘運行線程的每個號碼 - 讓響應時間

Max Wait = 10000ms我可以用10,20,30,40,60和80個線程執行JDBC請求而不出錯。使用Max Wait = 20000ms，我可以更高，並執行100,120,140個線程而不會出錯。這似乎是合乎邏輯的行爲。

現在的問題。 我可以根據需要增加最大等待值嗎？如何獲得更多測試結果是否正確？ 如果在某些報告中發生任何錯誤，我應該停止測試並且不要增加線程數量嗎？我有例如來自10000個樣本的誤差爲0.06％。這是爲我的測試停止嗎？ 謝謝。

Answer 1

此設置映射DBCP -> BasicDataSource -> maxWaitMillis parameter，根據文檔：

到拋出前歸還該池將等待（如果沒有可用的連接）的連接的最大毫秒數異常或-1無限期地等待

它應該與您的應用程序數據庫配置的相關設置匹配。如果您的目標是確定最高性能 - 只需在那裏輸入-1，超時將被禁用。

關於這是停止爲我的測試？ - 它取決於多個因素，例如應用程序在做什麼，您試圖實現什麼以及正在進行哪種類型的測試。如果您測試的數據庫安排核電廠操作比零誤差閾值是唯一可以接受的。如果這是一個貓的圖片庫，這個錯誤級別可以被認爲是可以接受的。

在大多數的情況下，性能測試分爲幾個測試執行，如：

1. Load Testing - 使系統預期的負載下，看它是否能夠處理用戶
的預測量
2. Soak Testing - 基本與負載測試相同，但保持負載時間較長。這允許檢測例如內存泄漏
3. Stress testing - 確定應用程序的邊界，飽和點，瓶頸等。從零負載開始逐漸增加，直到它突然提到用戶的最大數量，其他指標的相關性如響應時間，吞吐量，錯誤率隨着用戶數量的增加，檢查應用程序在負載恢復正常時是否恢復等。

請參閱Why ‘Normal’ Load Testing Isn’t Enough上述測試類型的文章詳細描述。

Answer 2

Everything depends on what your requirements are and how you defined performance baseline. 

我可以根據需要增加最大等待值嗎？如何獲得更多測試結果是否正確？

• 如果您在更高的響應時間內正常工作並且功能應該正常工作，那麼您可以儘可能多地保留最長時間。但是，實際上，響應時間的閾值（例如執行登錄事務的時間爲2秒）將作爲性能SLA或性能基準的一部分進行定義。所以，雖然你正在你的要求，通過增加最大一次成功，最終它被認爲是失敗的請求，由於高響應時間（由越過閾值）

注：DB操作更高的響應時間最終結果在Web應用程序（或最終用戶）響應時間更長的情況下

如果某些報告中出現任何錯誤，我應該停止測試並且不要增加線程數？

• 同樣適用於錯誤率。如果SLA表示，某些％錯誤率已達成一致，那麼如果實際錯誤率低於此值，則可以考慮測試符合SLA或性能基準。例如：如果要求表示0％錯誤率，那麼0.1％也被認爲是失敗。

這是停止爲我的測試？

• 你可以在任何你想要的地方停止測試。它完全基於您想要捕捉的指標。據我所知，建議繼續測試，直到達到無法繼續測試的地步，例如錯誤率達到99％等。如果錯誤率爲0.6％，那麼我建議繼續通過測試，瞭解系統的突發點，如服務器崩潰，響應時間達到不可接受的值，內存問題等。

以下是一些很好的參考：

1. https://www.nngroup.com/articles/response-times-3-important-limits/
2. http://calendar.perfplanet.com/2011/how-response-times-impact-business/
3. difference between baseline and benchmark in performance of an application
4. https://msdn.microsoft.com/en-us/library/ms190943.aspx
5. https://msdn.microsoft.com/en-us/library/bb924375.aspx
6. http://searchitchannel.techtarget.com/definition/service-level-agreement
名