- 概述：Eclipse Test & Performance Tools Platform (TPTP) 的性能測試工具(Profiling tool)能夠用于優化eclipse插件應用、本地的java應用，乃至是運行在多臺不同平臺主機上的復雜應用，Profiling tool與eclipse緊密地結合在一起，能在Eclipse環境下運行性能測試。
- 應用的性能測試：要在短暫的開發周期里提交一個產品是當今的流行趨勢，開發人員（不得不）將更多的精力關注在應用執行的功能方面，大多是通過測試、調試來穩固代碼；然而，許多缺陷除非經過每天24小時，每周7天的連續運行是不容易暴露的。這類缺陷是不能通過調試程序的方式來發現。在發布一個產品之前，通過性能分析工具去分析應用的執行和驗證性能問題是很重要的，例如：瓶頸、對象泄漏、系統資源局限。本文介紹了TPTP性能測試工具，示范了如何利用TPTP性能測試工具去定位出一個java應用性能缺陷潛在點，以及修復、驗證結果。
- TPTP 測試工具（翻譯略）
- 利用TPTP對Java程序進行性能測試 ：本文舉了一個簡單的關于product 分類的java應用例子，product的信息存儲在分散的一些xml文件當中，這個應用將解析這些xml文件，然后把結果輸出到控制臺，這些xml文件的路徑可以通過程序變量傳遞main函數讀取，本例的源代碼及xml文件下載連接：ProductCatalog_example.zip以及products.zip
- 在性能測試視圖中開始應用：下載上述的ProductCatalog_example.zip，解壓后導入某個java項目下,選擇Product類-->右鍵--->Profile As --> Java Application，如下圖：
圖一
通過Profile As-->Java Application菜單打開如下對 話框，如圖二所示。對于這個例子來說，通過程序參數來設置包含產品信息的xml文件的文件夾路徑，從圖二可以看到，設置程序參數為x:/myPath/products,其中x:/myPath/products文件夾是你從本文中提供的products.zip 下載解壓到本地的路徑。
下一步是通過設置性能測試選項作為收集執行信息的方法。設置這些選項，可以點擊Launch configuration properties 向導中的Monitor頁，選擇一組適合的性能選項。提示：一組性能測試過濾器是能夠被復用的。設置性能測試過濾器的目的是為了在連續相同的測試中復用，或者是在需要相同的性能測試信息時共享這些過濾器。以下的各個步驟描述了怎樣創建一個用于剖析Product catalog的應用的過濾器。我們將創建一個叫ProductFilterSet,用于剖析包名前綴為com.sample.product 的包。
- 在Monitor頁中選擇Execution Time Analysis選項,如下圖
正如上圖所示，我們選擇的Execution Time Analysis選項能作用于product catalog 程序的連續運行期間，在下一次運行該程序的時候，可以跳過設置性能測試過濾器的步驟。
2. 選擇編輯選項
2a.選擇Collect boundary classes excluded by the filter set選項，設置Boundary class depth的值為3。通過選擇這個選項，你指明你想收集的信息是：符合過濾條件的方法以及被該方法調用深度不超過3層的方法。例如：假設我們設置的過濾器去收集MyMethod的信息，并且過濾出方法：M1,M2,M3,M4。
如果調用棧是如下執行的：MyMethod>M1>M2>M3>M4，基于在2a中設置的過濾條件，性能解析器將顯示如下的調用棧：MyMethod>M1>M2>M3,將不顯示最后一級調用M3>M4（因為超過了3層）。如下圖所示：
3.選擇要剖析的類
在Moniter頁中，選擇Java Profiling項，然后雙擊或者單擊編輯按鈕，打開The Filter Set 向導。利用The Filter Set 界面來選擇你想剖析的類，這里已經預先定義了一組可用的過濾器，就本例來說，你可以通過下面幾步創建一個新的過濾器：
3a）單擊Add..按鈕，在彈出的對話框中輸入ProductFilterSet，然后單擊OK。
3b)使用Contents of selected filter set列表中的Add按鈕增加兩個過濾器，如下圖所示：
可以通過在Launch Configuration wizard向導中點擊OK按鈕來運行Product catalog 程序，在詢問是否切換到Profiling and Logging透視圖時選擇Yes,你將在Console視圖中看到如下圖所示的結果：
提示：TPTP性能測試工具允許你和你所剖析的程序之間交互。你能暫停、恢復監聽，運行垃圾收集回收對象引用或者中止程序的運行。
- 使用Execution Statistics視圖分析性能危險點
使用Execution Statistics視圖去分析性能危險點，在Profiling Monitor視圖中，右鍵-->Open with > Execution Statistics可以打開Execution Statistics視圖，下圖顯示的是按照方法調用的累積時間排序的，累積時間是指該方法花費的所有時間，包含調用其他方法的消耗的時間。
正如上圖所示，Execution Statistics 顯示在最上方的方法：main(java.lang.String[]), readData(java.lang.String) 和createParser() 消耗了最多的執行時間。看見main和readData方法在列表中（的位置）是不奇怪的，因為前者是程序執行的開始點，后者從其名字可以看出它從xml文件中讀取產品信息。
使我們覺得奇怪的是方法createParser() ，它僅僅創建了用于解析xml文件的SAX parser 實例就花費了如此高的執行時間。該方法的執行時間占了整個應用的執行時間的42.96%,Execution Statistics 幫助我們分析這個方法是性能優化的潛在的地方。
分析到這里，讓我們看看createParser() 方法的執行細節。
- 通過方法createParser() 打開Method Invocation Details 視圖
下面我們通過Method Invocation Details 視圖來看看createParser() 調用慢的原因。在Execution Statistics視圖中雙擊createParser() 方法就可以打開Method Invocation Details 視圖，如下所示：
上圖中顯示了方法createParser()的執行信息，就像你看到的一樣，該方法被readData(java.lang.String)調用了一次，同時它調用了5個不同的方法，在invoked methods 表中，你能看見newSAXParser() 和newInstance() 方法可能就是createParser()方法執行慢的原因，這兩個方法跟createParser()被調用24次一樣，也被執行了24次。
通過分析以上這些數據，我們發現改進createParser()執行時間的一個途徑就是改進SAXParserFactory的兩個方法的執行，既然我們無法控制這些方法的實現，唯一的途徑就是減少調用這些方法的次數。
解決方案是創建一個parser實例，并且復用其去解析所有的xml文件，取代原來每解析一個文件就創建一個parser實例的做法。讓我們打開源代碼并且修復它。
提示：在進行任何之類優化之前，要確保被代碼支持。例如，當SAXParser不能同時被多線程使用時，實例能被復用；嚴格來將，實例在復用之前應該被重置（reset），擁有一套全面的單元測試集來檢驗這些修改是個不錯的主意。
可以在Method Invocation Details視圖中右鍵-->Open Source來打開源代碼。源代碼如下圖：
上圖中顯示了createParser()方法的源代碼。注意該方法每次調用都創建一個新的SAX parser 。更新代碼，只創建一個parser實例，復用于解析每個xml文件,如下圖所示：
正如在上圖中描述的，定義了一個全局的SAXParser 實例變量parser，createParser()方法初始化parser然后在每次被調用時返回該實例。
讓我們再次執行一下Product catalog程序，驗證修復的結果。
在Java透視圖中選擇Product類，右鍵--->Profile As -->Java Application,程序執行完后，打開Execution Statistics 視圖，比較執行時間，下圖所示的是做了性能優化后的結果：
正如你看到的，createParser()方法的執行時間已經僅有19%,而在優化執行卻是將近 43%。注意，隨著xml文件數量的增加，提升的值將更加明顯，所以，隨著product文件的增加而減少的程序執行時間將是指數級的。
總結：
本文論述了TPTP性能測試工具能被用于分析和解決性能問題，本文沒有涉及TPTP工具更多的其他使用方面，如果你想了解更多的關于TPTP工具的能力，有一套的教程和用戶手冊在這里。