本节提供了 Identity Manager Profiler 功能的概述。信息通过以下方式进行组织:
可以使用 Profiler 实用程序来执行以下操作
创建性能分析数据的“快照”。
“快照”是自上次重置所有收集到的分析结果以来累积的性能分析结果。
使用四种不同的数据视图来显示快照结果:
“调用树”视图提供了一个树表,用于显示整个系统的调用计时和调用计数。
“热点”视图提供了节点的平面化列表,用于显示汇总调用计时(不考虑父节点)。
“反向跟踪”视图提供了反向的调用栈,显示了从中调用该节点(称为根节点)的所有调用链。
“被调用者”视图提供根节点的汇总调用树(不考虑其父调用链)。
指定要包含在快照中的信息类型:
可以包含表单、工作流和 XPRESS 的所有元素,或将内容限制为一组特定的元素。
可以选择要包含在分析中或从分析中排除的特定 Java 方法和构造函数。支持对 Identity Manager 类和自定义类进行分析。
按如下方式管理项目快照。
将快照保存在项目的 nbproject/private/idm-profiler 目录中或项目以外的任意位置。
在 "IDM Profiler" 视图的“已保存的快照”部分,可以查看所有已保存快照的列表。
从项目中打开快照,或从项目之外的某一任意位置加载快照。
删除快照。
按名称搜索特定的节点。
本节介绍了 Profiler 如何查找和管理以下 Identity Manager 对象的源:
在“调用树”视图或“热点”视图中,可以双击任何与 Java 方法、工作流、表单、规则或 XPRESS 对应的节点,以查看该节点的源。
在使用 Profiler 拍摄快照时,服务器会评估所有的性能分析数据并发现该数据所依赖的源。然后,服务器将从系统信息库中获取所有这些源,并将它们包含在快照中。因此,您可以确信显示在快照中的 Identity Manager 对象会准确地反映捕捉到该快照的那一刻的情况。
此过程会增加快照的大小,但相对来说,源大小实际上只是总大小的一小部分。因此,您可以将快照发送到 Sun 的客户支持部门,而不必单独发送源文件。
在拍摄 Java 源的快照时,客户机将下载该快照,然后仔细查看快照以便从项目中捕获所有引用的 Java 源。在保存快照时,客户机将压缩这些源并将其附加到快照的结尾处。
然后,在您查看快照并转至 Java 源时,客户机将首先检查快照的内容。如果客户机在该处找不到快照内容,则会检查项目的内容。此过程允许您发送包含性能分析数据(来自自定义 Java 代码和 Identity Manager 代码)的快照。
在 Java 源快照中,不能假定源相对于服务器而言是最新的或始终可用。
以下各节包含评估 Profiler 提供的结果时要考虑的信息:
要计算根节点的自用时间,Profiler 将从根节点的总时间中减去所有子节点的时间。
因此,未分析的子节点的时间会反映在根节点的自用时间中。如果根节点的自用时间很长,则应该查明原因。您可能没有分析适当的方法,因此导致您处理的位置不当。
例如,假设方法 A 调用方法 B。
方法 A 总耗时为 10 秒(这里总时间包括调用方法 B 的时间),并且调用方法 B 总耗时也为 10 秒。
如果分析了方法 A 和 B,则调用栈会反映出该信息。您将看到,方法 A 的自用时间为 0秒,而方法 B 的自用时间为 10 秒(这 10 秒实际上是在方法 B 中花费的)。但是如果未分析方法 B,则只会看到调用方法 A 耗时 10 秒,并且 A 的自用时间为 10 秒。因此,您可能认为问题就是出在方法 A 中,而不是方法 B 中。
需特别指出的是,您在最初编译 JSP 期间,会注意到 JSP 的自用时间很长。如果您重置收集的结果,然后再重新显示该页,则自用时间将会显著减少。
因为 Java 分析策略中存在某些限制,所以 this() 或 super() 的初始调用将显示为构造函数调用的同级调用,而不是子级调用。请参见以下示例:
class A { public A() { this(0); } public A(int i) { } } and: class B { public static void test() { new A(); } } The call tree will look like this: B.test() -A.<init>(int) -A.<init>() Rather than this: B.test() -A.<init>() -A.<init>(int) |
不要被表面上许多 Identity Manager 守护线程(如 ReconTask.WorkerThread.run() 或 TaskThread.WorkerThread.run())所耗费的大量时间所误导。其中大部分时间是在休眠(等待事件)中度过的。必须仔细研究这些情况,以了解这些线程在处理事件时实际使用的时间。