J2EE性能測試（1）

版權聲明：本文為部落客chszs的原創文章，未經部落客允許不得轉載。 https://blog.csdn.net/chszs/article/details/1544657

J2EE性能測試（1）

1、問題：

1）應用程式的運作有多快？

2）它将适用于多大的規模？

3）應用程式伺服器的性能是什麼？

2、The Grinder的負載生成/資料收集工具

The Grinder是一個基于Java的工具。

3、J2EE性能測試

1）性能測試一個完整的應用程式；

2）性能設計——分析J2EE API不同方面的性能代價，以及某種設計決策對總體性能的影響。

性能依賴于應用程式以及性能的确切含義。

J2EE是一組廣泛的API，甚至一個相對簡單的J2EE應用程式都可以以多種方式編寫。

前端：有一組JSP和servlet處理與終端使用者或用戶端的通信，或是将通路委托給一個實體bean；

前端可使用JDBC與資料庫通信；

開發人員可選擇讓該前端調用一個無狀态的會話bean；

然後該無狀态的會話bean使用JDBC API與資料庫通信，或者是将該通路委托給一個實體bean；

實體bean可以使用容器管理的持久性（Container-Managed Persistence，CMP）或者是Bean管理的持久性（Bean-Managed Persistence，BMP）等。

4、擷取清晰的真實的有關性能的答案的唯一方法是，在你自己的特定環境中親自測試它。

1）互動式應用程式：性能一般是通過大小和規劃問題的容量來定義，如應用程式能夠處理的同時發生的使用者數量。

從終端使用者的角度看，關鍵的性能屬性是響應時間。

響應時間直接受到同時與應用程式互動的使用者數的影響。

随着使用者負載的增加，測試應該指出工作繁忙的硬體系統元件，可反過來告知如何在應用程式伺服器、資料庫伺服器和網絡之間最佳的分割硬體預算資源。

該資訊還能夠幫助确定最優的部署配置。

前端（servlet和JSP）可以運作在一個應用程式伺服器上，而事務邏輯（EJB、JMS隊列）運作在另一個伺服器上。

2）後端應用程式

當應用程式的主要接口是面向使用者時，基于響應時間和使用者數的性能陳述是有意義的；當應用程式具有與另一個系統的接口時，需要：

吞吐量來衡量。

表達吞吐量性能最流行的方式之一是每秒的事務處理（Transactions per Second，TPS）。

使用吞吐量必須清楚地說明了上下文。

在研究servlet時，我們定義事務處理為一個請求——是以吞吐量是servlet在一個設定的時間周期内（一秒）執行的同樣請求的數量。

當分析JMS時，吞吐量就是消息（message）。

注意：吞吐量不是一個速度測度，而是一個容量（capacity）測度。

吞吐量并不總是提供應用程式性能的完整描述。

5、上下文測試方法

1）基準測試（Benchmarking）：是在各種不同的環境和工作負載下記錄應用程式性能的過程；

2）輪廓（Profiling）：涉及到精确地調查應用程式将大部分計算周期花費在什麼地方，以及應用程式如何高效地使用系統資源；

3）調整（Tuning）：測試、基準測試和輪廓都回報給調整過程，後者是優化應用程式和環境擷取最大性能的過程；

6、基準測試

ORACLE資料庫——輪廓工具SQL_TRACE和TKPROF；

WEBLOGIC伺服器——WEBLOGIC控制台檢視起内部情況；

J2EE應用程式——Introscope和JProbe輪廓工具來幫助準确查明應用程式中元件級的瓶頸。

7、調整

一個典型的J2EE應用程式将建立在一個應用程式伺服器的基礎上，此外，還有資料庫、Java虛拟機（JVM）、作業系統、TCP/IP堆棧、Web伺服器、網絡、路由器和現行的計算機硬體。