爲什麼在使用Jmeter加載測試與HP Load runner時出差？

Question

這裏是場景

我們正在加載測試一個web應用程序。該應用程序部署在兩臺虛擬機服務器上，並分配負載的硬件負載平衡器。

這裏使用的工具有兩種： 1. HP Load Runner（一種昂貴的工具）。 2. JMeter - 免費

JMeter被開發團隊用來測試大量的用戶。它也沒有像Load Runner這樣的許可限制。

測試如何運行？ 使用一些參數調用URL，Web應用程序讀取參數，處理結果並生成PDF文件。

當運行測試時，我們發現對於1000個用戶在60秒內傳播的負載，我們的應用程序需要4分鐘才能生成1000個文件。 現在，當我們通過JMeter傳遞相同的URL時，1000個用戶的加速時間爲60秒， 應用程序需要1分15秒來生成1000個文件。

我對此感到莫名其妙，爲何這種巨大的性能差異。

負載運行程序在兩臺服務器上都安裝了rstat守護進程。

任何線索？

Answer 1

你真的在這裏有四種可能性：

1. 您測量兩個不同的事情。檢查你的時間記錄結構。
2. 您的請求和響應信息在這兩種工具之間是不同的。與Fiddler或Wireshark一起檢查。
3. 您的測試環境初始條件不同會產生不同的結果。測試101的東西，但在追蹤這樣的問題時經常被忽視。
4. 您的loadrunner環境中有一個負載生成器過載，導致所有虛擬用戶速度變慢。例如，您可能會記錄導致您的文件系統成爲測試瓶頸的所有內容。刻意減少生成器，減少日誌記錄級別，並觀察如何使用內存進行關聯，以免創建物理內存超額認購條件，從而導致高交換活動。

正如上面以JMeter的速度更快的評論，我已基準都和用於非常複雜的代碼LoadRunner的所述C基溶液是在執行時不同次迭代比JMeter的基於Java的溶液更快。 （方法：爲批量抵押處理動態創建數據文件的複雜算法，p3：800Mhz，2GB內存，LoadRunner每小時180萬次迭代，對於單個用戶不受影響JMETER，120萬）一旦添加了它，是服務器對兩者都確定的響應時間。

需要注意的是，LoadRunner會跟蹤其內部API時間，以直接處理影響測試結果的工具的指責。如果打開結果集數據庫集（.mdb或適當的Microsoft SQL Server實例）並查看[事件計量器]表，您將找到「浪費時間」的參考。浪費時間的定義可以在LoadRunner文檔中找到。

Answer 2

最有可能的罪魁禍首是腳本的結構。

需要考慮的事項：

• 思考/等待時間：錄音時， 的JMeter不會自動投放 等待。
• 正在請求的項目：是 Jmeter只請求/下載 HTML頁面，而Load Runner全部獲取 嵌入文件？
• 無效回覆： 都是1000的Jmeter回覆有效嗎？ 如果你有一個 單個桌面的1000個線程，我會懷疑你的 死了Jmeter，並不是你的所有 響應都是有效的。

Answer 3

不要忘記，測試應用程序本身會測量自己，因爲響應的到來是基於測試機器的時間。所以從這個角度來看，它可能是答案，JMeter只是更快。

第二件要提及的是BlackGaff提到的等待時間。

總是用jmeter中的結果樹檢查結果。

並且總是將測試應用程序放到單獨的硬件上以查看真實結果，因爲測試應用程序本身會加載服務器。