5. 右鍵單擊您剛創建的 HTTP 請求並選擇
Add > Timer。計時器添加請求之間的 “思考時間“。這模擬一個用戶單擊一個頁面，然後暫停閱讀頁面上的一些信息，最後發出另一個請求。您可選擇許多預定義的計時器，具有從常量固定計時器到高斯或泊松分布式計時器的不同複雜度。JMeter 用戶手冊
記錄每個可用的計時器。對於這個簡單示例，僅使用 5 ms 的
Constant Timer。
6. 右鍵單擊該線程組並轉到
Add > Listener > Summary Report。這將顯示測試運行時的響應時間和吞吐量結果。
7. 將設置保存到一個文件，以便您可在以後再次加載它們。
運行測試
在啟動負載驅動工具之前，始終要確保應用程序兼容一個瀏覽器。準備好後，單擊綠色箭頭或單擊
Run > Start。JMeter 現在應將一個客戶端連接到您指定的服務器路徑，在每個請求之間等待 5 ms。如果您單擊
Summary Report，可以看到測試運行的結果。
您應會注意到，吞吐量在不斷增長；這稱為 “升溫” 階段。JRE 需要一些升溫時間來加載所有類，讓 JIT 執行一些優化。吞吐量最終將穩定，達到一個固定的數量（每秒發出或接受一些請求）。依賴於測試的複雜性，這個升溫階段可能持續 30 秒，也可能持續 30 分鐘。
在測試運行時，打開一個終端（Linux 或 AIX）並運行
vmstat 5
來每隔 5 秒顯示一次系統指標（參見清單 1）。
清單 1
|
[root@spice3 bin]# vmstat 5 procs ———–memory———- —swap– —–io—- –system– —–cpu—– r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 8235164 104920 500956 0 0 13 11 44 154 8 5 86 0 0 0 0 0 8235164 104928 500956 0 0 0 3 8030 4987 6 1 93 0 0 1 0 0 8235040 104936 500956 0 0 0 3 7982 4944 5 1 94 0 0 0 0 0 8233116 104936 500960 0 0 0 6 8126 5020 7 1 92 0 0 0 0 0 8231068 104944 500960 0 0 0 6 7952 4939 6 1 93 0 0 0 0 0 8231316 104952 500960 0 0 0 3 7761 4819 5 1 94 0 0 Example vmstat output showing ~7% CPU utilization. |
如果使用 Windows，右鍵單擊任務欄並選擇任務管理器，然後選擇性能選項卡。當 JMeter 中的吞吐量達到一個穩定值後，記錄運行 WebSphere Application Server 的服務器和任何其他適用服務器上的 CPU 利用率，然後單擊紅色停止標誌或
Run > Stop
停止 Jmeter 測試。JMeter Summary Results 視圖類似於圖 5。
圖 5. JMeter Summary Report 視圖
在一個電子表格中，記錄吞吐量結果（93.9 個請求/秒）和平均響應時間結果 (4 ms)。如果您希望更詳細的信息，那麼 Min、Max 和 Std. Dev. 響應時間也很有用。
記錄所有結果後，選擇
Run > Clear
來清除 Summary Report 結果。這會介紹對單個用戶的測試。現在將用戶數量依次增加到 2、4、8 等，並重複上述步驟。每次添加更多用戶時您都應觀察到吞吐量增長。最終，您會觀察到吞吐量停止增長，甚至可能開始下降。達到平穩狀態（以及可能下降）時，測試即可停止。
分析結果
完成上述步驟後，您應得到一個類似圖 6 的電子表格。（這些具體的結果高度依賴於 DayTrader 應用程序和運行此測試的環境。您的實際結果可能有很大不同。）
圖 6. Test Results – Table 視圖
擁有這樣的表列格式的原始數據很有用，但以圖形格式查看結果也很有用。可視化結果的一種最佳方式是使用 XY 散點圖。繪製一個圖表來描繪結果，會使趨勢的識別容易得多。圖 7 描繪了吞吐量和 WebSphere Application Server CPU % 與客戶端數量的關係。
圖 7. Test Results – Graph
上面的圖 7 顯示了一些有趣的特徵。首先，可以看到吞吐量曲線和 CPU % 曲線非常接近。第二，可以看到應用程序吞吐量從 1 個客戶端近線性地擴展到 500 個客戶端。這是想要的結果。但是，在 500 個客戶端到 1,000 個客戶端之間的某個點，吞吐量的增速開始放緩。（這時可使用 500 到 1,000 之間的用戶負載來執行更多測試，以查找發生此增速放緩現象的準確位置。）將客戶端負載增加到 1,000 個客戶端以上不會改進總體應用程序吞吐量。這就是所謂的飽和點。這是一個重要的值，必須在性能測試中找到。飽和點告訴您，您已達到此應用程序、調節、配置和環境的最大容量。添加超過此點的更多用戶只會增加客戶端響應時間，不會增加總體應用程序吞吐量。要獲得超過此點的更高性能，必須執行應用程序代碼更改、調節更改或環境更改。
DayTrader 與您的應用程序對比
DayTrader 不能代表所有應用程序。您的應用程序可能更早達到飽和點。如果情況確實如此，這可能表示一個應用程序瓶頸，需要執行應用程序分析來修復它。
這種類型的測試和分析是大小調整和容量規劃討論中主要主題。只有通過識別飽和點，您才能準確估算支持一個生產環境所需的總容量。常常有人會說，“我需要在此環境中支持 10,000 個用戶“，然後對該客戶端負載運行測試。通常，此方法會在一個或多個組件中引起各種各樣的超負荷情形，這些情形可能在 WebSphere Application Server 中，也可能在其他基礎設施組件（網絡、數據庫等）中。一種更高效的方法是確定使用單個應用服務器可獲得何種客戶端負載和吞吐量，然後基於此信息繼續執行運行時和應用程序調節。調節完成後，可將注意力轉向確定滿足可伸縮性需求需要多少應用服務器流程和流程服務器。
將一個新測試保存在 JMeter 中，使用您找到的線程（用戶）數作為飽和點。這可用作一項快速測試，以對比您對應用程序或環境執行更改時的性能，而無需再次執行完整的可伸縮性測試。這不是說您不應再執行可伸縮性測試，但對於在 CPU 未充分利用的更低負載上不會顯示出任何不同的更改，運行飽和點上的負載是對比這些更改的一個不錯地方。一種不錯的做法是對次要應用程序或調節更改運行飽和點負載，對主要應用程序或環境更改重複完整的可伸縮性測試。
性能工具
以上各節是執行任何真實分析工作的準備條件。您必須首先理解如何生成可重複的性能結果，才能查找瓶頸和性能改進。現在您已準備好查找改進了，應使用以下兩個性能工具來開始分析：
• IBM Tivoli® Performance Viewer Tivoli Performance Viewer（在管理控制台中）是一個監視 WebSphere Application Server 的非常有用的工具。這篇文章
重點介紹了使用 Tivoli Performance Viewer 最優地調節環境的好處。採用相同的方式，Tivoli Performance Viewer 可用於快速檢查是否有任何可通過調節輕鬆刪除的瓶頸。
以下是一些開始使用 Tivoli Performance Viewer 的簡單步驟：
1. 使用比確定為飽和點的用戶數量重新啟動 JMeter 負載。
2. 登錄到管理控制台並選擇
Monitoring and Tuning > Performance Viewer > Current Activity。單擊您希望監視的服務器，然後展開
Performance Modules。這將顯示一組可供查看的性能模塊。
3. 您的應用程序特徵將確定其中哪些模塊最有必要查看。對於 DayTrader 示例或任何其他基於 Web 的流量，啟動
Thread Pools > WebContainer
模塊。勾選該複選框，單擊頂部的
View Module
按鈕。這將顯示一個類似於圖 8 的圖表，在 JMeter 測試繼續運行時，每隔 30 秒自動填充更多數據。
圖 8. WebContainer PMI 數據
此示例顯示，WebContainer 線程池大小為 50 個線程，其中大約 32 個正在使用。這告訴您，WebContainer 線程池大小不是當前工作負載下的瓶頸。如果活動數量在 45-50 之間波動，那麼 WebContainer 線程池大小可能是一個瓶頸。在該情況下，可能最好增加 WebContainer 線程池大小，重複該測試以查看性能是否改進。如果吞吐量確實增加了，您可能希望再次運行灣鎮的可伸縮性測試，以重新建立基準。
4. 對其他適用於您的應用程序的模塊繼續重複第 3 步。對於 DayTrader 這樣的事務應用程序，應查看的另一個模塊是 JDBC Connection Pool 信息。展開
JDBC Connection Pools > 您的 JDBC 驅動程序），選擇您的數據源 JNDI 名稱。單擊
View Module
按鈕以顯示一個類似圖 9 的圖表。
圖 9. DataSource PMI 數據
以下文章點擊率最高
Loading…