[发明专利]用于收集应用性能数据的系统和方法

说明书

背景技术

关键业务应用中的性能问题通常难以在测试环境中再现。在至少一些情况下，这可能是由于这些应用是针对试生产（pre-production）环境中的性能而测试和调谐的并且是针对性能测试合格后的生产而发布的。当应用面临真实负载和真实数据时，测试环境通常难以甚至不可能测试将在生产环境中执行应用的所有条件。

通常，仅以不频繁的间隔暴露生产中的性能问题，例如当遇到具体数据、具体用户交互、具体数据库状态和/或具体定时的特定组合时。由此，检测并识别导致性能问题或难题的条件可能是挑战性的。

现今的服务器侧应用的常见架构模型基于反应原理。具体地，服务器在通过明确定义的协议（HTTP、RMI、SOAP等）接收到外部事件（请求）时执行一些工作，并可以向请求方发送响应（结果）。在接收到单个事件时执行的工作的单位有时被称作“服务器请求”。服务器性能的主要指示器是服务器请求等待时间，即，接收请求事件直到发送响应之间经过的时间。

性能分析师可能有兴趣确定哪些服务器请求的执行耗费较长时间。存在旨在解决该需要的多个可用工具。性能分析师还可能有兴趣看到长期运行服务器请求的内部细节，以便理解并查明延迟的根本原因。这可能提出严格的技术挑战。在同服务器请求的执行有关的所收集的数据的量和质量与数据收集的性能开销之间一般存在较强的权衡。以下事实使该权衡甚至更加深刻：当服务器请求开始时，服务器请求等待时间不是已知的；并且，大多数数据收集技术不能够追溯地捕获数据。因此，在先系统可以强制所有服务器请求的数据收集或者请求的随机选择的子集的数据收集，并冒着丢失导致问题的服务器请求的风险。

附图说明

图1是根据实施例的用于收集应用性能数据的系统的框图；

图2是根据实施例的由报告模块形成和显示的服务器请求调用树的表示；

图3是根据实施例的用于使用执行服务器请求的应用线程的信息收集应用性能数据的方法的流程图；以及

图4是根据实施例的用于使用应用线程的时间戳收集应用性能数据的方法的流程图。

具体实施方式

现在将参照所示意的示例实施例，并且这里将使用特定的语言来描述这些示例实施例。然而将理解，并不意在由此限制本发明的范围。本发明的附加特征和优势将从结合附图作出的以下具体实施方式中显而易见，这些附图一起作为示例而示意了各个技术实施例。

生产环境中部署的多层服务器应用所遇到的故障解决性能问题可能对信息技术（IT）人员来说是挑战性的任务。应用性能约束通常不允许使用剖析工具（profiling tools），并且，性能问题无法始终在测试环境中再现。随着应用复杂度的升高以及应用更频繁地使用一个或多个第三方组件，查明服务器请求的长等待时间的根本原因对应用的开发者来说可能是困难的。克服这种困难的先前努力仅收获了有限的成功。

这里描述了一种用于收集应用性能数据以找到所部署的业务应用中的故障点的系统和方法，其克服了上述困难中的许多困难。对跟踪、采样和其他数据收集技术的使用可以在以下多个级别进行：

1）在数据收集级别，最小化采样和跟踪的重叠，并将开销保持为较低；

2）在数据处理级别，调解采样和跟踪技术操作的不同方式；以及

3）在图形用户界面级别，给用户提供统一体验。

两种用于收集应用性能数据（即“剖析”）的技术是跟踪和采样。跟踪有时被称作基于事件的剖析，并基于插桩（instrumentation）。插桩可以是为了捕获所选函数的起始和结束而对应用代码的修改，并可以是自动的。插桩有时被扩展为捕获函数自变量、所选数据点或与应用执行相关的其他工件（artifact）。跟踪能够产生与应用执行有关的非常丰富和精确的信息，但是跟踪经受非常大的开销。典型的基于跟踪的剖析器在平均Java语言应用中对所有函数（方法）进行插桩时可以施加约2500-4000%的开销。换言之，与没有剖析的相同应用相比，经过剖析的应用消耗中央处理单元（CPU）的约25至40倍的处理能力。这种大的开销可能使跟踪剖析器实际上不可用在生产环境中。