進行實時監控
簡介：了解在性能測試中應用程序監控為什麼重要，以及如何使用 IBM Rational Performance Tester 來進行應用程序監控。 本文是一個三部分系列文 章的第 2 部分，描述了如何使用 IBM Rational Performance Tester 來檢查開 發和測試階段的應用程序瓶頸，進而減少產品階段的問題。本系列的其它部分介 紹了如何為監控應用程序配置 IBM® WebSphere® Application Server 或者 BEA WebLogic Application Server、分析測試結果以及從 IBM® Tivoli® 產品中導入數據。
實時應用程序監控能夠通過 IBM® Rational® Performance Tester 在開發和測試期間預先發 現應用程序的瓶頸。這種方法是有用處的，由於它可以在應用程序部署到產品環 境前發現問題，這樣可以 降低應用程序發布後出現的嚴重的問題。另外，您還可以使用實時應用程序監控 來驗證開發組修改過的應 用程序的性能。
數據收集架構
Rational Performance Tester 中 的實時應用程序監控是使 用數據收集底層架構（data collection infrastructure，DCI）來進行的。DCI 的任務是把 Application Response Measurement (ARM) 標准事件傳送給用戶，這個事件是由 ARM-instrumented 的 應用程序報告給 IBM® Tivoli® ARM 引擎的（參見圖1）。
圖1： 使用 DCI 的系統架構
事務流
為了理解整個架構，考慮一下貫穿整個環境的業務事務的流程是有幫助的 ：
在監控時，在 根事務要執行的機器上的 DCI 必須啟動。例如，執行一個對 http://ibm.com/PlantsByWebSphere 的 HTTP 請求就表示應用 PlantsByWebSphere 必須被啟動，而且 DCI 要安裝在 ibm.com 所在的機器上。
客戶端調用應用程序的 HTTP 事務，這個應用程序是已經 ARM- instrumented 的。您可以使用下 面的客戶端：
Rational Performance Tester： 在測試執行每個頁面的 HTTP 請求時，它的行為與浏 覽器類似。在響應時間分解（response time breakdown (RTB)）激活時， Rational Performance Tester 給請求加上 ARM_CORRELATOR 頭屬性，這就可以激活 DCI 以監控事務。這個客戶 端可以在根事務將要運 行的機器上自動地建立與 DCI 的連接。
網絡浏覽器：運行給定 URL 的 HTTP 請求。您必須手動 地建立到根事務將要運行的機器上的 DCI 連接。
由於事務調用的應用程 序工作在運行環境下，工 具代碼（或者探針）將會執行（閱讀第一部分可以得到有關探針的更多信息）。 這些探針將會初始化由 Tivoli ARM 引擎監控的 ARM 事務。
IBM® Performance Optimization Toolkit 代理（下面 簡稱為 Toolkit 代理）是一個基於 Java™ 技術的應用程序，它實現了 Tivoli 提供的 ARM plug -in 接口，目的是用 Tivoli ARM 引擎注冊第三方應用程序。當 ARM 事件生成並 報告給引擎時，它們同 時報告給 Toolkit 代理。事件按照從根事務到所有子事務的層次進行收集和整理 。然後轉換為按照 Eclipse Test and Performance Tools Platform (TPTP) 跟蹤模型格式的事件集 合。然後事件集合被傳 送到展示系統。
目標系統和展示系統之間利用 IBM® Rational® Agent Controller 互相 通訊。這個部件與 Eclipse TPTP 集成，作為 Rational Performance Tester 的 基礎。這個部件也管理 toolkit 代理（啟動和停止監控）。
每個報告給 DCI 的事件都包含 ARM 事務啟動和完成時間的 信息，這些信息添加到元數據中。這些時間信息有助於進行度量，然後可以對此 進行分析以確定是否存在 性能問題。元數據能夠幫助表示事務在整個事務層次中的上下文和被調用事務的 類型。
執行環境
在執行環境中，有兩個代理用來實現 Java 性能分析接口：
適時 編譯(JITI)，IBM® Tivoli® Java™ 2 Platform, Enterprise Edition (J2EE™) 監 控組件
Java™ Virtual Machine (JVM™)。 API 稱為 JVM Profiling Interface，有時簡稱 為 JVMPI。
本系列文章的第 1 部分討論了 JITI。在 Eclipse TPTP 中使 用的 JVMPI 代理在 Rational Performance Tester 中已經得到加強，增加了如安全特性、支持與 Citrix 和 SAP 的集成等 。
在您設置監控應用程序的性能分析配置時，您需要選擇分析類型，以便 確定您想要收集的數據 類型。根據您選擇的分析類型，DCI可以用一個代理進行數據收集，也可能兩個代 理都使用。代理是按照 您的性能分析設置自動選擇的。兩個代理的區別如下：
ARM 代理在以下情 景中最有用：
在分析 J2EE應 用程序性能和程序失敗時，特別是在事件高度相關的分布式應用程序中。
在分析 ARM- instrumented 應用程序時。例如，如果您ARM了一個數據庫，您可以從您的應用 程序中觀察事件直到進入 數據庫中，可以看到在數據庫中的全部處理過程，然後看到響應的返回，所有這 一些都顯示在一個序列圖 表中。
JVMPI 代理在以下情況下最有用：
進行內存性能分析時（例如 內存洩漏分析）。
在檢查對象的相互作用時（例如 UML2 對象關系視圖）。在很多情況下， 類的相互作用分析足以 幫助發現問題，但是您偶爾可能需要進行更深入的對象級別的分析。
在對 非 J2EE 的應用程序進 行分析時，例如 Java™ 2 Platform, Standard Edition (J2SE™) 或者 Java™ 2 Platform, Micro Edition (J2ME™) 應用程序。
每個代理都具有自 己的數據收集特性，如 表1所示：
表1：ARM 和 JVMPI 代理之間的數據收集特性的對比
表 1. 表標題
特性 ARM 代理 JVMPI 代理 提供關聯進程 和主機遠程調用的能力 提供 不提供 當在 性能分析模式中運行代理 時回影響應用性能 影響小 影響大 提供過 濾機制 根據 J2EE 組件類型(例如， servlet 或者 JDBC), 主機 URL 根據包、類和 方法 收集內存信息和對象交互（對於 UML 2 對象交互圖） 沒有 有
兩個代理有可能並行地使用，這時執行環境的負載會 顯著地增加。因此，增 加了 profiling interface (PI) virtualizer （Windows 系統下是 virt.dll 文件）。這個部件僅僅對 JVM 識別的內容進行代理。當 PI virtualizer 從 JVM 接收到事件後，它把這些 事件廣播到它檢測到的 每個基於 JVMPI 的代理。在這種情況下，那些代理是 JITI 和 Java 性能分析代 理。
為了使用 Java性能分析代理，您需要增加以下虛擬機參數：
- XrunpiAgent:server=enabled
當 PI virtualizer 存在時，使用 這個 VM 參數：
-Xrunvirt:agent=jvmpi:C:\PROGRA~1 \IBM\DCI\rpa_prod\TIVOLI~1\
app\instrument\61\appServers\server1_100 \config\jiti.properties,agent=
piAgent:server=enabled
注意參數指定了接收廣播事件的所有兩個代理。在前面討論過 的工具的配置文件中可以找到同樣的配置。
數據收集底層架構（Data collection infrastructure）
為了收集端對端的事務信息，DCI 必須安裝在事務通過 路徑上的所有系統上， 如圖2所示（更多的端對端事務的信息可參見第一部分）。之所以有這個要求是因 為 ARM correlator 跨 越了物理機器的邊界。因此，當 ARM correlator 從一台機器傳遞到另一台機器 時，在機器上接受 ARM correlator 的 DCI 必須執行一個特殊的過程，稱為動態發現。
圖2：分 布式環境下的 DCI
動態 發現過程的目的是自動化地添加客戶平台和開始對遠程方法調用的機器上的 DCI 的監控。這樣做的原因 是，當一個事務第一次執行時，只有事務路徑上的第一台機器的客戶端會被添加 進來。因此，與其期望您 知道任意一個給定事務調用的所有的物理機器並手工添加它們，不如進行自動化 的操作。
這個過 程設計得可以在 ARM correlator 中傳遞有關調用機器上的代理控制器（Agent Controller ）的信息。 因此，在調用 RMI-IIOP 事務時，ARM事件被傳遞到新發現的機器上的 DCI（RMI -IIOP 代表 Remote Method Invocation [RMI] Internet Inter-ORB Protocol [IIOP]）。 這個 RMI-IIOP 事務是由 toolkit 代理進行檢測的。這時，toolkit 代理在被調用的機器上使用代理控制 器向調用機器上的代理控 制器調用一個同樣的請求。這個請求再調用機器上已知的客戶端，並給新發現的 機器建立連接（參見圖3 ）。這樣，事務信息依次地從被調用的機器上流動到要分析的客戶機。
說 明：
在動態發現 工作時，代理控制器的安全特性必須關閉。在本文2007年5月初次發布時，安全特 性仍然不能全部支持分 布式環境。為了關閉安全特性或者檢查是否關閉，執行位於代理控制器安裝目錄 下的 bin 目錄的 SetConfig 腳本。
圖3：動態發現過程
在多數情況下，我們的 興趣集中在從應用程序服務中收集事務信息上。因此，有一些數據庫系統（如 IBM® DB2®）包括 在 ARM 工具產品中。使用這個 ARM 工具可以對端對端事務進行深入的監控。例 如，與只能夠知道事務從 Java 應用中使用 Java DataBase Connectivity™ (JDBC™) 調用了 SQL 事務相比，分析人 員可以從執行特定查詢的數據庫內部得到事務信息。這些信息可以很大程度上幫 助縮小 Java 應用或者軟 件方案的數據庫產生的問題的范圍。
激活端對端事務監控的第一步是簡單 地按照數據庫產品手冊 的指導激活 ARM 工具
第二步是在數據庫運行的同一台機器上安裝 DCI。 在監控模式下啟動 DCI 將允許數據庫事務信息傳遞給客戶機。
此外，您可以進行配置以便准確地 收集數據庫上運行的查 詢。為了激活這個配置，您必須關閉數據庫對本地 DCI 的安全性。激活收集 SQL 查詢的方法如下（您只 能在已經 instrumented 的應用程序服務器上進行以下步驟）：
關閉應用程序 服務和 DCI。
進 入以下目錄： <DCI_INSTALL_DIRECTORY>/rpa_prod/tivoli_comp/app/instrument/61/ap pServers/<serverna me>/config
打開 monitoringApplication.properties 文件。
添加以下兩行：
tmtp.isPrivacyEnabled=false
tmtp.isSecurityEnabled=false
啟動 DCI。
啟動 應用程序服務。
初始化調用事務的數據收集。
配置 Rational Performance Tester
在您運行性能測試或者性能調度時，可以使用 Rational Performance Tester 中的 Response Time breakdown，響應時間分解特性來查看任何被分析的頁面元素的統 計。響應時間分解會顯 示出被測系統的每個部分花費了多少時間。響應時間分解視圖與特定的測試或者 調度執行的頁面單元 （URL）關聯。這將顯示出系統在測試時的內部情況，因為數據收集機制是在系統 測試下進行的，而不是 負載驅動的。
一般情況下您是在開發期間的測試環境下實時地獲取調度， 而不是在產品環境下。 為了獲取調度 ，您必須在測試時激活它，然後指定需要獲取的數據的數量。
為了配置性能測試， 需要進行以下工作：
在 Performance Test Editor 的 Test Element Details 中選中檢查框（參 見圖4）。
如果在 Test Contents 樹的最頂層節點被選中，然後在 Test Element Details 中選 擇 Enable response time breakdown，這樣將在性能測試時對每個頁面和頁面元 素進行監控。
如 果僅僅需要監控特定的頁面或者頁面元素，在 Test Contents 樹中進行選擇。這 將在 Test Element Details中顯示選擇的項目配置，以便您可以激活響應時間分解。
圖4：性 能測試中的響應時間分 解配置
為了配置性能調度，進行以下步驟：
在 Schedule Element Details 下， 選擇 Response Time Breakdown 標簽，並選擇 Enable collection of response time 數據。這將激 活測試列表和 Options。
在激活 response time breakdown data collection 後，設置 logging detail levels（參見圖 5）。
圖5：在性能調度中的響應時間分解配置
Response Time Breakdown 頁可以讓您設置您要在運行時看到的數據類型、這些數據的樣本率以 及收集所有用戶的數據還 是特定用戶的數據。
激活收集響應事件數據：選擇這個選項將激活響應時 間分解的收集。這將針 對每個頁面元素顯示響應時間分解。
Detail level: 選擇 Low 或者 Medium將限制收集的數據數 量。這個選擇越高，則事務跟蹤得越深，收集的數據的數量就越多。例如，當選 擇 Low 時，只有表層事 務被監控。在基於J2EE的應用程序中，就是 Servlet。當增加選擇的水平時，就 開始收集 J2EE 應用程序 的 enterprise JavaBeans™ (EJBs) 和 RMI 的數據。
Only sample information from a subset of users: 如果您設置了 detail level 為 High 或者 Medium，則需要 設置 sampling rate 以 防止日志變得過大。
Fixed number of users: 您在每個用戶組中選擇的 作為樣本的用戶數。除非 您有特定的原因收集多個用戶的數據，否則您應該選擇 Fixed number of users 並為每個用戶組指定一 個用戶。
Percentage of users: 您從每個用戶組中選擇的作為樣本的用 戶占的百分比，但每個用 戶組中至少會有一個用戶。
在性能測試中激活響應時間分解不會影響任何 性能調度中的響應時間 分解。反之依然，在性能調度中激活響應時間分解也不會影響性能測試中的響應 時間分解配置。測試和調 度是互相隔離的實體。
在進行了合適的響應時間分解配置之後，您必須執 行測試或者調度以在負 載測試期間初始化應用程序監控。這可以通過使用 Run 菜單來啟動測試或者 調 度。只有在通過 GUI 運 行測試或者 調度時，響應時間分解才能夠啟動。如果測試或者 調度配置了響應 時間分解，使用命令行執 行，則響應時間分解的數據不會被收集。
實時觀察性能分析
在開 發環境中，您可以用以下 分析方法收集響應時間分解的數據：
您可以在開發環境中對運行的分布式 J2EE應用程序進行性能 分析（通過收集 響應時間分解數據）。
您也可以在使用自動化測試工具 運行應用程序時進行分析 ，這樣可以讓您很容易地重復運行有問題的場景並模擬應用程序的實際負荷。
您可以使用 IBM® WebSphere® Application Server 分析應用程序的 Web 服務組件 。
您可以分析非 J2EE應用程序或者任何由 ARM 標准支持的其它語言開發的應用程序。
為 了收集實時的響應時間分 解數據，必須確保您完成了以下幾點：
DCI必須在所有要收集數據的機器 上安裝、配置和運行。更 多的信息可以查看安裝指南。
所有相關機器上的代理控制器（DCI 的一部 分）端口必須設置為缺 省值 (10002)。
應用程序系統不能包含內部 IP 地址和網絡地址轉換 （NAT）的網絡通信。
在從應用程序系統中收集和分析實時的響應時間分解數據之前，您必須建 立到 DCI 的連接。首先 ，要識別將要處理初始事務請求的服務。更明確地說，識別事務請求到達的第一 個應用程序服務。
說明：
在您要監控的分布式應用程序中，您不必明確的創建到每 個相關機器的連接。通過 動態發現過程，在事務流到達相應的機器時，連接會自動建立。
要初始化 實時數據收集，執行以 下步驟：
選擇 Run > Profile，或者使用工具欄按鈕打開 Launch Configuration 對話框（見 圖6）。
這個動作讓您切換 Rational Performance Tester 的 Profile and Logging 的視圖。這 個視圖激活性能分析工具並在工作台上用不同的視圖布局。
圖6：Profile 啟動配置動作
Profile Configuration 對話框可以讓您創建、管理和運行實時應用程序監控的配置。使 用這個方法可以監控那些 沒有進行自動化監控的J2EE、非J2EE和Web service應用程序，這可以適用於性能 測試或者調度的情況。
在 Launch Configuration 對話框中，選擇 J2EE Application，然後單 擊New （參見圖7）。如 果您的應用程序不是運行 J2EE 應用服務，而是根據 ARM 標准進行了手工操作， 選擇 ARM Instrumented Application。
在 Host 頁面，選擇代理控制器的主機。如果您需要的主 機不在列表裡，單擊 Add ，然後提供 host name 和 port number。
在開始運行前測試連接。
圖7：Profile 針對 J2EE 應用程序的啟動配置：Host 頁面
在 Monitor 頁面的 Analysis type 中，選擇 J2EE Performance Analysis，或者如果您對使用 ARM -instrumented 的應用程 序進行分析，選擇 ARM Performance Analysis （見圖8）。
如果您想要 自定義性能分析設置和過 濾器，點擊 Edit Options。
圖8：Profile 針對 J2EE 應用程序的啟動配 置：Monitor 頁面
在 Components頁面，選擇您要收集數據的 J2EE components 的類型（見圖9）。
圖9：用於監控的 J2EE 性能分析組件
在 Filters 頁面，指定您要監控的主機和事務。 filters 指示您想要 收集的數據類型。它們 包括，而不是排除數據（見圖10）。
圖10：應用 J2EE 性能分析過濾器
在 Sampling 頁面， 您可以限制收集數據的數量。這可以通過選擇所有數據收集的 fixed percentage 或者 fixed rate 來實 現（見圖11）。
Sample a percentage of all transactions: 性能分析有選 擇性地收集和放棄事務。 例如，如果設置為25％，則第一個事務調用收集，後面三個不收集。
Sample a specific number of transactions each minute: 收集每分鐘的前 n次調用（這裡 n是指定的值） ，其余的不收集。因此 ，您在一分鐘之內將從來不會接受到超過 n次的調用。
圖11：J2EE 性能 分析采樣選項
您可以 設置 filter 和 sampling 來指定收集多少數據。filter 指定您想要收集哪些事 務，而 Sampling指定您 想要收集的事務數據的數量或者百分比。Filters 和 sampling 在根事務層次工 作。根事務就是不屬於其 它事務（至少是數據收集有關的事務）的子事務的事務。
因此，在使用浏 覽器訪問一個Web應用時 ，根事務就是第一次點擊到服務的URL請求。 filtering 和 sampling 應用在這 個級別。也就是說，如果 您設置了事務的 filter，它在 URL 級別工作。如果您設置了 sample，它只收集 一些 URL，而放棄另一 些。要麼是整個 URL，要麼都不是，它不會收集 URL 事務的一部分。
如 果 Web 應用駐留在多個 服務器上，有些 ARM-instrumented，有些沒有，只有 instrumented 的服務器被 包括進來。例如，如果 用戶訪問了服務器 A，它沒有ARM-instrumented，而服務A使用了一個方法調用訪 問了服務 B，B 是 ARM -instrumented，這樣這個方法就是根事務。這時 Filtering 將不會工作，因為 它是使用URL而不是方法 名字來進行過濾。
同樣，如果您正在使用性能測試或者調度產生性能分析 數據，根事務將發生在 第一個 ARM-instrumented 的測試單元運行時。如果整個測試或者調度都是 ARM -instrumented（也就是 說，在頂層測試或者調度單元選擇了Enable response time breakdown），這就 將僅僅只有一個根事務。 這時 filtering 和 sampling 都將是無效的。
在您開始監控之前，把應 用程序設置為在就要出現 性能問題的狀態。例如，如果一個特定的 Web 頁面的動作導致變慢，那就打開這 個網頁。
單擊 Profile。已經連接的代理和它的主機和過程都將顯示在 Profiling Monitor 視 圖（見圖9）。根據您的 性能分析配置，如果在分布式環境下工作的話，可能會顯示出超過一個的代理。
通過選擇代理並 Start Monitoring 來啟動監控。如果性能分析配置中有超過一個代理，啟動每個 代理。符合您前面設置 的應用程序的任何活動都將會記錄下來。代理的狀態由 <attached> 轉換 為 <monitoring> ，在從代理接收到數據時，狀態轉換為 <monitoring...collecting>。
圖12：J2EE 性能分 析的監控
在應用程序中，執行可以觸發性能問題的操作。
在彈出菜單中 選擇 Stop Monitoring來 停止監控代理。在最好的情況下，斷開同代理的連接，以便其它用戶可以監控系 統。在彈出菜單中選擇 agent 和 Detach。對收集數據涉及的每個代理重復這個步驟。
尋找性能 問題的原因
很多 代碼問題都會導致應用程序失敗，對每個問題您都必須使用數據收集和分析技術 以及合適的工具來研究。 典型的應用程序失敗包括 stoppages，這時應用程序不期望地中止，以及 lockups，這時應用程序停止響 應，例如進入和死循環或者等待永遠也不會發生的事件。
在 lockup 的情 況下，您可能不會看到 任何實際的錯誤日志。這時可以使用相互作用圖，統計圖和線程分析工具來發現 問題所在。例如，如果問 題是死循環，UML 序列圖將會顯示您在重復調用序列，統計表也會顯示方法花費 了很長的時間。如果問題 是 deadlock，線程分析工具將會顯示哪個線程是您期望它工作，但是實際上在等 待永遠也不會發生的東 西。
在您收集了響應時間分解數據後，就可以使用性能分析工具對數據進 行分析，以便確定哪部 分代碼導致了問題。一般來說，您需要首先把問題范圍縮減到導致出現問題的部 件。然後您可以繼續進行 分析，把范圍縮減到哪個包、類，直到找到導致問題的方法。當您找到出現問題 的方法後，就可以直接到 源代碼中修復了。
您可以在 Test 視圖中查看響應時間分解數據，或者如 果執行了性能測試或性 能調度的話，您可以在 Profiling and Logging 視圖中查看。另外，如果您手工 運行 J2EE 應用程序或 者進行了 ARM-instrumented 配置，收集的數據只能在 Profile and Logging 視 圖中查看。
跟蹤 這樣的問題可能包括嘗試－出錯－再嘗試的過程，您可以用不同的方式進行收集 和分析數據。您可能會找 到您自己的最好的工作方式。
Rational Performance Tester 報告分析
在性能測試或者性 能調度執行完畢後，Rational Performance Tester 會給用戶生成一個缺省的報 告。有兩種機制用來分析 響應時間分解數據（參見圖13）。
Response time breakdown 統計：給出 事務或者子事務對特定 頁面或頁面元素響應事件的表格。
Interactive reports: 用圖形來表述 事務的分解
圖13 ：頁面性能報告的樣例
在這兩個報告中，下 面的層級提供了對事務和子事務進行組織和分類的結構：
主機：應用程序 執行方法上下文所在的 物理主機。
應用程序：觀察到的方法執行的應用程序。典型地，對於J2EE 應用來說，就是應用服 務。
應用程序部件 一個組織好的標簽或者元數據，給出方法調用的上下 文。對於 J2EE 應用程序 來說，方法調用可以標記為 Session EJB，也就是應用程序部件。
包： 類和方法調用上下文屬於 的包。
類：方法調用上下文所屬的類。
方法：特定方法的調用。
使用統計視圖進 行分析
在 Page Performance 報告中選擇 Display Response Time Breakdown Statistics 選項 將顯示出事務或者子事務對特定頁面或頁面元素響應事件的表格。首先，有一個 Page Element Selection Wizard （見圖14），以便您可以選取特定的頁面單元以查看它的事務 分解。所有的頁面單元 都按照各自響應時間的大小降序排列。
圖14：Page Element Selection 向導
Response Time Breakdown Statistics 的頂層視圖顯示出選擇的頁面元素的所有的子事務的集合 （見圖15）。這個視圖 中有不同的工具用來幫助分析性能問題。
使用左上角的導航信息返回前一 個視圖。
使用右 上角的工具欄，主要功能有：樹型界面和簡單界面之間切換、增加過濾器、選擇 顯示哪些欄、調轉到源代 碼、在百分比和數值之間切換、導出到 CSV、HTML 和 XML 格式。
圖15： Response Time Breakdown Statistics 視圖
目錄（樹）的布局也 顯示出以下層次（圖16）：
主機
應用程序
部件
包
類
方法
在您的企業環境下的每個主機排成一列。在每個主機下，排列著應用程序 。每個應用程序下，排 列著部件，等等
樹型布局（見圖16）有助於您識別響應事件最慢的排列。
圖16：響應時間 分解統計：樹型布局
使用右上角的工具欄 的第一個按鈕可以在樹型布局和簡單布局之間切換。缺省的布局是簡單布局。
簡單布局是樹型布 局的平鋪版本。如果您想要看到所有的方法而不關心它們之間的關系的話，可以 使用這個布局。這樣可以 快速地看到最慢或者最快的方法。
點擊 column heading可以按照該列進 行排序。拖動列可以改變 它們顯示的順序。除了樹型布局的第一列外，其余列都是可以拖動的。選擇的頁 面元素的准確的URL顯示 在表上方。
每個對象顯示四個結果：Base Time、Average Base Time、 Cumulative Time 和 Calls。所有時間單位都是秒。這些時間的定義如下：
Base Time 這個對 象內部消耗的時間，不包 括這個對象調用其他對象的時間消耗。
Average Base Time 是這個對象內 部消耗的時間，不包括 這個對象調用其他對象的時間消耗，除以調用次數
Cumulative Time 是這 個對象內部消耗的時間 ，包括它調用其它對象的時間。
Calls 是對象被其它對象調用的次數。
動作
圖17 顯示了工具欄按鈕（圖16中也顯示）和它們關聯的動作：
圖17：工具欄按 鈕
點擊 Filter 按鈕（ 從工具欄左邊數第二個）將打開 Filters 窗口。您可以增加、修改和刪除用在顯 示結果上的過濾器。
點擊 Columns 按鈕（第三個）將打開 Select Columns頁面。這裡可以選 擇表中顯示哪些列。在 當前工作區中的設置將會應用到工作區中的所有響應時間分解表中。
點擊 Percentage 按鈕（第 四個）將在顯示百分比和絕對數值之間切換。在百分比格式中，表中顯示的數據 為百分比，而不是實際的 數值。百分比表示一個欄目中的值占該欄中所有值之和的百分比。
點擊 Source 按鈕（第五個） 將調轉到源代碼（如果可用）。在您點擊這個按鈕前必須首先選擇一個方法。
點擊 Export 按鈕 （第六個）將打開 New Report 窗口。您可以把 響應時間分解表導出為 CSV、 HTML 或者 XML 格式。
使用左上角的導航信息可以返回前面的視圖。
在過去，交付時間 和響應時間的計算上有一 定的混淆。如果您很熟悉性能測試的話，這裡的響應時間並不等於 Rational Performance Tester 定義 的術語。要用下面的定義代替：
交付時間： 最後接收到的時間 － 首次 接收到的時間
響 應時間： 首次接收到的時間 － 首次發送的時間
在查看 GIF 文件的事務 分解時，正常情況下您 可以看到非常小的交付時間（通常是零）。因為這個文件的數據流是在一個單獨 的包內到達。然而，如果 服務在很長時間後才響應，您一般可以看見服務對文件頭的響應比其余部分要快 。在這種情況下，響應可 以分解到幾個包中。
說明：
您總能看到交付時間和響應事件。您 也可是看到標記為 DNS Lookup 和 Connect 的事務請求。
交互式圖形分析
交互式圖形分 析主要是使用存在的 Rational Performance Tester 報告對事務分解用圖形的方式向下詳細（drill- down）的過程。如果您通 過選擇 Display Page Element Responses 進行響應時間分解的分析（見圖13） ，您可以用柱狀圖顯示出 選擇的頁面的所有頁面元素的響應（見圖18）。
圖18：響應時間分解的圖 形詳細報告
從這個頁面元素詳細 報告中，您可以選擇對特定的元素的主機、應用程序和部件、包、類和方法的響 應進行更深入的詳細活動 。柱狀圖上的鼠標右鍵上下文菜單可以顯示出當前報告中可用的詳細動作。例如 ，如果您正在對特定的事 務查看應用程序的響應時間分解，上下文菜單將顯示出查看選擇的應用程序的應 用程序部件的響應時間分 解項（見圖19）。
在每個詳細過程的層次上，導航的路徑都會更加詳細一 些。這種行為提供了一 種很容易的方式可以在在分析過程期間跳轉到不同報告。您也可以直接在任何詳 細圖上選擇直接跳轉到 Response Time Breakdown Statistics視圖中。
圖19：組件層詳細報告
實時觀測的性能分析
UML Sequence Diagram 視圖中存在一系列的因果依賴事件，這些事件定 義為方法實體和出口，也 包括外部調用和返回調用（見圖20）。特別地，它存在類實例之間的交互作用。 這些交互作用的形式是方 法調用和調用返回。Trace Interaction 工具的實現擴展了這個定義，推廣了進 行交互作用的角色，和交 互作用的含義。換句話說，工具提供的視圖不僅僅可以顯示類和類實例的交互作 用，而且可以顯示線程、 進程和主機之間的交互作用。這種擴展的主要原因是在大型分布式應用程序的跟 蹤時需要提供分層次的數 據表示形式。
圖 20：UML Sequence Diagram 視圖
可以用視圖連接服務 來幫助分析相互關聯的應用程序跟蹤事件，這個服務在 UML Sequence Diagram 視圖和統計和日志視圖中 都可用（見圖21）。關聯使用兩個事件的發生的時間來計算。如果沒有找到精確 的時間匹配，則選擇可接 受范圍內的下一個時間最接近的事件作為關聯事件。
圖21：在 UML Sequence Diagram 和統計/日 志視圖的視圖連接服務
Execution Statistics 視圖顯示應用程序執行時間的統計結果（見圖22）。它可以提供諸如 方法調用次數和執行每 個方法的時間的統計。這個視圖在包、類、方法和實例的層次可用：
Base Time: 對任何調用，它 是執行調用的時間消耗，不包括在調用期間調用其它方法的時間消耗。
Average Base Time: Base time 除以調用次數
Cumulative Time: 對任何調用，它是從一個調用中執 行其它所有方法調用所 花費的時間。如果一個調用沒有附加的方法調用，Cumulative Time 則等於 Base Time。
Calls: 方法調用次數
圖22：Execution Statistics 視圖
提示：
可以對 整個方法列表按照 Base Time 大小排序。這樣將把最消耗處理時間的方法排在最 上面。為了這樣做，可 以選擇項目，然後用鼠標右鍵菜單打開 various analysis 選項。從 Execution Statistics 視圖中選擇 項目，然後就可以顯示鼠標右鍵上下文菜單（見圖23）。
圖23： Execution Statistics 視圖的鼠 標右鍵上下文菜單
在這個菜單中，下面的選項值得您去執行：
Open Source: 如果 源代碼導入了當前的工 作區，這個選項可以讓您自動地打開與選擇的包、類和方法關聯的源代碼。
Method Invocation Details: 提供有關選擇的方法的統計數據，包括有關調用的方法和方法被其它方 法調用的信息。您可以 在任何分析視圖中（如 Method Invocation、 Execution Flow 或者 Execution Statistics）選擇一個 方法，然後打開這個視圖（見圖24）。
圖24：Method Invocation Details 視圖
Method Invocation Details 視圖顯示以下內容：
Selected method: 顯示方法的細節信息， 包括選擇的方法被調用的 時間、類和包的信息、以及時間消耗。
Selected method invoked by: 顯 示調用該方法的每個方 法的信息，包括調用該方法的次數、調用該方法的時間。
Selected method invokes: 顯示該方法 調用其它方法的細節信息，包括調用的方法名、調用的方法時間、調用方法的次 數、被調用的包和類的信 息，被調用方法的時間消耗。
使用 Rational Performance Tester 進行 應用程序監控的三部分系 列文章的第 2 部分到這裡就結束了。
