如何使用jmeter和visualVM進行負載測試？

Question

我想爲我的網站爲1000萬用戶進行負載測試。該網站是一個基於Java的網絡應用程序。我的方法是爲所有鏈接創建Jmeter測試計劃，然後爲1000萬用戶提供報告。然後使用jvisualVM進行分析並檢查是否存在瓶頸。

有沒有更好的方法來做到這一點？有沒有現有的演示？我是第一次這樣做，所以任何援助都會非常有幫助。

Answer 1

我在博客裏，我的表現進行測試的方式：

1. 確保服務器（硬件可以按照分期/生產要求）沒有安裝其他可能影響性能。
2. 有關設置在DB中的用戶而言，一個程序可以使用，並且可以被稱爲JMeter測試計劃的一部分。
3. 在單獨的機器上安裝jmeter，以便jmeter不會影響性能。
4. 創建JMeter的測試計劃（如該圖所示1）對所有的URI，以響應檢查和基於定時器的請求。
5. 以jmeter作爲初始基準。
6. 檢查低性能的uri。這些是瓶頸預期的要點。
7. 嘗試以提高性能不同的選擇，但只集中在一個瓶頸的時候。
8. 嘗試從第6步開始的任何一個修復，然後進行基準測試。如果有任何改善提交更改並重復步驟5否則恢復，並嘗試從第6步
9. 任何其他選項的下一步將是使用負載均衡，硬件縮放，集羣等，這可能包括一些物理設置和硬件/軟件成本。使用可伸縮性選項給出結果。

對於詳細的解釋：http://www.daemonthread.com/2011/06/site-performance-tuning-using-jmeter.html

Answer 2

你是在正確的道路上，但你的負載限制是一個很高的因素。

爲什麼我說這是因爲您的網站可能需要更多的機器來處理10Milj併發用戶。一個進程可能會很難處理併發的32K TCP流。還要做一些實際處理10Milj用戶所需帶寬的數學計算。

現在我不知道您想要在您的網站上提供什麼樣的服務，但是當考慮到JVisualVM將處理速度減慢了10倍（或更多方法跟蹤）時，您實際上不會測量「真實世界「，如果你讓JMeter和JVisualVM同時工作。

當您在較低負載下運行時，JVisualVM更有用。

要創建一個良好的測量首先確保您有一個良好的基準。 對10個併發用戶進行測試，連接JVisuamVM並讓它運行一段時間，而不是所有有趣的值。

有了基準後，您就可以開始添加更多的負載。 加載10倍負載（ea：100個用戶），查看JVisualVM中的更改。繼續執行此操作，直至JVisualVM明顯減慢速度，每次增加額外負載時，確保已寫下您感興趣的數字。在圖表中繪製數字。

現在...插入圖表（手工）爲您想要的用戶數量。這適用於內存使用情況，光盤訪問等，但不適用於使用的CPU時間，因爲JVisualVM會吃掉CPU，並給你提供無效的數字（尤其是如果你打開了方法跟蹤）。

如果你真的想要高達10Milj的用戶，我也不會相信JMeter，我會寫一個我自己的測試程序來執行你想要的測試。這可能是個竅門，因爲設置站點來處理10Milj也需要時間，所以花費額外一些時間的測試工具並不是浪費。

Answer 3

僅僅因爲您的數據庫中有1000萬用戶，並不意味着您需要使用該許多用戶加載測試。想一想 - 你的網站真的會有1000萬同時用戶嗎？對於Web應用程序，註冊用戶比例爲1：100是常見的，即您在任何時候都不會有超過10萬個用戶。

JMeter能處理那種負載嗎？我對此表示懷疑。請嘗試使用faban。它非常輕便，可以在單個虛擬機上支持數千個用戶。您還可以在創建工作負載時擁有更好的靈活性，並且還可以自動監控整個測試基礎架構。

現在來分析部分。你沒有說你使用的是什麼服務器。任何Java應用服務器都將提供足夠的監控支持。商業服務器提供了很好的GUI工具，而Tomcat通過JMX提供了廣泛的監控。在開始研究JVM級別之前，您可能需要從這裏開始。

對於JVM，您真的不想在運行如此大的性能測試時使用VisualVM。除了支持這樣的負載之外，我假設你正在使用多個appserver/JVM實例。主要的性能問題通常是GC，因此使用JVM選項來收集和記錄GC信息。您將不得不後處理數據。

這是一個不平凡的練習 - 祝你好運！

Answer 4

有兩種類型的負載測試 - 瓶頸識別和吞吐量。這個問題讓我相信這是瓶頸，所以用戶數量是一個鯡魚，而目標是給定的配置找到可以改進的地方，以提高併發性。

應用程序瓶頸通常分爲三類：數據庫，內存泄漏或慢速算法。發現它們涉及將應用程序置於壓力（即負載）下長時間 - 至少一個小時，或許長達幾天。 Jmeter是一個很好的工具。要考慮的事情之一是運行啓用cookie處理的相同測試（即Jmeter保留Cookie並隨每個後續請求發送）並禁用 - 有時會得到非常不同的結果，這很重要，因爲後者實際上是模擬某些內容爬蟲對你的網站做。對於瓶頸檢測如下詳細說明：

數據庫

表沒有索引或涉及多個連接的SQL語句頻繁應用的瓶頸。我處理的每個數據庫服務器，MySQL，SQL Server和Oracle都有一些記錄或識別運行緩慢的SQL語句的方法。 MySQL具有較慢的查詢日誌，而SQL Server具有動態管理視圖，可以跟蹤運行速度最慢的SQL。一旦掌握了緩慢的語句，就可以使用解釋計劃來查看數據庫引擎正在嘗試做什麼，使用任何提示索引的功能，並考慮其他策略（如非規範化） - 如果這兩個選項不能解決瓶頸問題。

內存泄漏

打開詳細垃圾收集日誌記錄和JMX監控端口。然後使用提供更好圖的jConsole觀察趨勢。特別是泄漏通常表現爲填補老一代或Perm Gen空間。泄漏是JVM花費越來越多的時間嘗試垃圾收集失敗之前的瓶頸，直到引發OOM錯誤。

Perm Gen意味着需要增加空間作爲JVM的命令行參數。雖然Old Gen意味着應該停止負載測試的泄漏，但要生成一個堆轉儲，然後使用Eclipse內存分析工具來確定泄漏。

慢算法

這是更加難以追查。最頻繁的違規者是同步，進程間通信（例如RMI，Web服務）和磁盤I/O。另一個常見問題是使用嵌套循環的代碼（查看媽媽O（n^2）性能！）。

我發現找不到一些更深層次知識的最佳方法是生成堆棧跟蹤。這些將告訴所有線程在給定的時間點正在做什麼。你正在尋找的是BLOCKED線程或幾個線程都訪問相同的代碼。這通常會導致代碼庫中的某些緩慢。

Answer 5

我開始使用JMeter plugins。
這使我可以收集JMX上可用的應用程序指標以用於我的負載測試。