哪個更好的基準策略：本地機器vs遠程機器

Question

今天我有一個辯論是更好的基準策略：本地機器vs遠程機器。我想知道關於該主題的其他意見。這是更一般的問題，但在這種情況下，它是一個Java項目。

測試是關於某些模板引擎的性能如何。 經過30秒的預熱階段後，基準線運行120秒，並有100個線程。

被測頁面有一些靜態和動態部分。像表和列表中的隨機項，但是例如靜態頭（不包括數據庫操作）。

塞納里奧1：

的Web服務器和基準測試工具運行在同一臺機器上。 測試用ab和jmeter進行。

臨參數：

• 生產也將是不理想的系統。
• 其他java進程也可能運行在生產系統上。
• 即使基準測試工具減慢導致平均的結果仍然有效（更好的技術將是對任何變體更好）

精讀參數：

• 在同一臺機器試圖擊敗本身
• 基準減緩真正的性能

塞納里奧2：

遠程機器測試其他系統：

臨參數：

• 一個系統可以嘗試到達其他
• 基準的限制（JMeter的）上不運行同一個JVM

精讀參數：

• 生產系統不會是一個理想的環境
• 網絡可能的結果

首先，我想知道這是更好的方式去減緩。其次，如果某些參數無效。或者最終它甚至不重要。我想知道這兩種變體的其他參數。我希望這個問題不會結束，因爲我認爲這不是一般的。一種選擇必須是更好的選擇。

Answer 1

情景2在幾乎所有情況下都將更接近生產行爲。我認爲情景1列出的利弊有效地使任何結果失效。然而，只要你符合這種方法，即使它們不符合你期望從生產中看到的結果，你也應該能夠使用結果進行比較。

解決方案2的缺點：

• 生產系統不會是一個理想的環境。

如果您即將加載測試生產，開始時會出現其他問題。

• 網絡可能會減慢結果。

雖然這可能是事實，但分佈式內部測試環境的網絡仍然比客戶從外部獲得的網絡要好。在幾乎所有情況下，您都會想要進行帶寬網絡模擬以確保類似生產的行爲。

要做到這一點，尋找在jmeter.properties文件以下行：

# Define characters per second > 0 to emulate slow connections 
#httpclient.socket.http.cps=0 
#httpclient.socket.https.cps=0 

這將限制每個JMeter的線程的「帶寬」。 （引用是因爲節流不會發生在網絡層面）做一個簡單的研究，看看CPS在您的應用程序方面意味着什麼。

---

答案很簡單：

總是試圖在分佈式安裝測試，因爲你有更多的靈活性。另外，請考慮您需要多個負載生成器機器來實際負載目標的情況。在這種情況下，你根本沒有選擇，所以我認爲「最佳實踐」是用單獨的負載生成器機器配置隔離的測試環境。

此外，爲了有效地最大化每個負載生成器機器的輸出，建議爲負載生成器機器定製打開的文件描述符限制（ulimits）和JVM內存設置。在大多數情況下，這些配置不適用於應用程序服務器。

希望幫助，請讓我知道如果我能進一步闡述， -Addled