利用TPTP对Java程序进行性能测试

         简单地说，TPTP 是一个EclipseFoundation 顶级项目，它的目标是：构建一个通用的可扩展的基于标准的工具平台，软件开发人员可以在这个平台上创建专用的可互操作的...和性能工具。TPTP
TPTP 为 UI 开发、数据收集、基于规则的数据查询以及应用程序的控制提供了基础代码。例如，TPTP 提供了其他工具可以重用和扩展的许多向导。它还提供了编程接口和一个守护进程，以便帮助从正在运行的本地或远程进程中收集数据。

TPTP Testing Tools

         这个项目是在 TPTP 之上构建的，提供了对应用程序进行各种自动化所需的其他服务。当前版本支持 JUnit 自动测试、一种指向和点击脚本编程系统（用于进行手工测试并记录结果）和一个用于测试 Web 应用程序的自动化系统，包括一个可以记录和回放 Web 浏览会话并对结果进行验证的记录器。EclipseV4.1 还包括一个图形用户界面（GUI）记录器的早期版本，它可以记录和回放基于 SWT 的界面中的鼠标和键盘事件。
TPTP Monitoring Tools
这个项目对来自日志文件或来自应用程序收集的统计数据的数据进行收集、分析和图形显示。
TPTP Tracing and Profiling Tools
这个项目也扩展了 TPTP，用来收集和分析正在运行的应用程序中的资源使用数据，包括 CPU 和内存。这个跟踪工具还允许与正在运行的进程进行交互。例如，可以手工地实施垃圾收集并检查剩余的对象池，从而寻找和修复内存 “泄漏”。
另外，TPTP 包括一个称为 Agent Controller 的守护进程。Agent Controller 是Eclipse工作台和被测试的应用程序之间的 “联络人”。它代表Eclipse启动本地或远程 应用程序并转发应用程序度量（包括应用程序日志文件）给Eclipse。

• 利用TPTP进行性能测试

这是翻译自eclipse官方网站的一篇文章。

原文地址：

原作者：Valentina Popescu, IBMFebruary 21, 2006

译文如下：

利用TPTP进行性能测试

1. 概述：EclipseTest & Performance Tools Platform (TPTP) 的性能测试工具(Profiling tool)能够用于优化eclipse插件应用、本地的java应用，乃至是运行在多台不同平台主机上的复杂应用，Profiling tool与eclipse紧密地结合在一起，能在Eclipse环境下运行性能测试。
2. 应用的性能测试：要在短暂的开发周期里提交一个产品是当今的流行趋势，开发人员（不得不）将更多的精力关注在应用执行的功能方面，大多是通过测试、调试来稳固代码；然而，许多缺陷除非经过每天24小时，每周7天的连续运行是不容易暴露的。这类缺陷是不能通过调试程序的方式来发现。在发布一个产品之前，通过性能分析工具去分析应用的执行和验证性能问题是很重要的，例如：瓶颈、对象泄漏、系统资源局限。本文介绍了TPTP性能测试工具，示范了如何利用TPTP性能测试工具去定位出一个java应用性能缺陷潜在点，以及修复、验证结果。
3. TPTP 测试工具（翻译略）
4. 利用TPTP对程序进行性能测试 ：本文举了一个简单的关于product 分类的java应用例子，product的信息在分散的一些xml文件当中，这个应用将解析这些xml文件，然后把结果输出到控制台，这些xml文件的路径可以通过程序变量传递main函数读取，本例的源代码及xml文件连接：ProductCatalog_example.zip以及products.zip
5. 在性能测试视图中开始应用：上述的ProductCatalog_example.zip，解压后导入某个java项目下,选择Product类-->右键--->Profile As --> Java Application，如下图：

图一

• 设置java程序参数

通过Profile As-->Java Application菜单打开如下对 话框，如图二所示。对于这个例子来说，通过程序参数来设置包含产品信息的xml文件的文件夹路径，从图二可以看到，设置程序参数为x:/myPath/products,其中x:/myPath/products文件夹是你从本文中提供的products.zip解压到本地的路径。

• 设置性能测试过滤器

下一步是通过设置性能测试选项作为收集执行信息的方法。设置这些选项，可以点击Launch configuration properties 向导中的Monitor页，选择一组适合的性能选项。提示：一组性能测试过滤器是能够被复用的。设置性能测试过滤器的目的是为了在连续相同的测试中复用，或者是在需要相同的性能测试信息时共享这些过滤器。以下的各个步骤描述了怎样创建一个用于剖析Product catalog的应用的过滤器。我们将创建一个叫ProductFilterSet,用于剖析包名前缀为com.sample.product 的包。

[NextPage]

1. 在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按钮增加两个过滤器，如下图所示：

• 运行程序

[NextPage]

可以通过在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次。

• 为诊断出的性能问题定义一个解决方案

[NextPage]

通过分析以上这些数据，我们发现改进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工具更多的其他使用方面，[NextPage]

如果你想了解更多的关于TPTP工具的能力，有一套的教程和用户手册在这里。

后记：

这是自己第一次不是为了自己而翻译e文，觉得真是够累的。因此，不由得向经常翻译e文的前辈、大师们致敬！

关于profiling的翻译：有的地方可能翻译成概要分析更好

【责编:Luzi】

--------------------next---------------------