CN102460408B - 用于收集应用性能数据的系统和方法 - Google Patents

Abstract

本发明提供了用于收集应用性能数据的系统和方法。系统（100）包括用于托管服务器侧应用（120）的服务器（110）。在服务器上包括插桩模块（130）。插桩模块可以选择性地对服务器侧应用的函数（125）进行插桩，以获得插桩函数操作数据。插桩模块还可以维持每个应用线程的插桩函数调用栈（190）。在服务器上包括采样模块（140）。采样模块可以对服务器侧应用的应用线程进行采样，以获得采样函数操作数据。采样模块可以基于通过插桩而获得的时间戳的寿命以及根据栈的空虚度而对哪些线程执行服务器请求的确定中的至少一个，对应用线程进行采样。

Description

用于收集应用性能数据的系统和方法

背景技术

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

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

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

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

附图说明

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

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

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

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

具体实施方式

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

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

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

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

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

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

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

采样是另一种剖析技术，并且基于对应用内的所有线程的栈跟踪（stack trace）的周期性检查。采样一般不产生应用内的函数的起始和结束事件，并且通常无法获取任何自变量。采样可以在一些时间点处捕获调用者-被调用者（即，从调用者调用的函数）关系，并且，函数等待时间可以是仅在使用采样时才估计的。采样的强度是其与跟踪相比相对较低的“成本”（即，开销）。典型的基于采样的剖析器在以较高频率（当前高至约每秒100次或更多）进行采样时可以施加约100%的开销（即，与没有剖析的相同应用相比，经过剖析的应用消耗约两倍的CPU）。

函数等待时间的近似的准确度随着所取的样本数而增大。可以提高采样频率，以增加样本数，但是，提高的采样频率也增大了开销。可替换地，剖析器可以运行更长时间以增加样本总数。这提供了针对平均或合计服务器请求的合理数据。然而，如果仅非常少的服务器请求表现出性能问题（通常是这种情况），则这可能不提供足够的数据以进行分析。因此，采样通常用于估算出应用一般在哪里花费了其大部分时间，但可能不适于甚至识别单独服务器请求。

一种可以满足严格性能限制并同时提供对应用专员来说有用的信息的技术是选择性代码插桩。在选择性代码插桩中，仅对应用内的少数函数进行插桩。该插桩提供了函数入口/出口事件，函数入口/出口事件被加时间戳并作为由应用执行的一个或多个服务器请求的调用树而呈现给用户。该调用树是不完整的，但是，对要插桩的函数的合适选择可以至少实现对经受性能问题的应用组件（一个或多个）或模块（一个或多个）的识别。

然而，选择性插桩仍然具有缺陷。尽管应用专员可能能够识别耗费较长时间完成的函数调用，但是如果不存在与被调用者有关的足够信息，则可能不会发现性能问题的根本原因。可以通过将新插桩插入应用中来获得与被调用者有关的信息。然而，这通常不是容易的任务。首先，性能分析师必须将应用代码理解得好到足以识别潜在被调用者，并必须确保所添加的插桩不会将性能开销增加至不可容忍的水平。其次，许多运行时环境不具有在运行时期间将插桩代码注入应用中的能力。这种插桩改变可能意味着应用将在插桩计划的每次改变时重新启动，并在生产执行期间带来各种业务级影响。

这里描述了用于收集应用性能数据的系统和方法。方法包括：选择性地对服务器上的服务器侧应用进行插桩，以获得包括应用线程的时间戳的插桩函数操作数据。对具有比预定时间段更久的时间戳的应用线程进行采样，以获得采样函数操作数据。将插桩函数操作数据和采样函数操作数据进行组合，以形成统一的应用性能报告。

参照图1，根据实施例，提供了用于收集应用性能数据的系统100。该系统可以包括被配置为托管（host）服务器侧应用120的服务器110。应用可以包括任何数目的函数125和任何数目的线程。可以向和从服务器发送应用请求170和响应180。例如，使用客户端160的用户可能希望访问web应用或与web应用对接。客户端可以向服务器发送针对信息的请求170。服务器可以向客户端发送响应180。本领域技术人员可以认识到，在客户端与服务器之间可以存在任何数目的设备（如路由器、交换机、其他服务器等），以便于在客户端与服务器之间传输数据。

在服务器110上可以包括插桩模块130。插桩模块可以被配置为对服务器侧应用120的函数进行插桩。可以通过对应用的插桩来获得函数操作数据。可以对任何数目的函数125进行插桩，并且可以将插桩函数插桩至任何期望的程度。然而，开销随着插桩的增加而增大。在一个方面，仅对所选择的函数进行插桩。此外，可以限制对所选择的函数的插桩，以便仅收集特定数据，从而将开销保持为较低。可收集的插桩函数操作数据的示例可以包括函数识别（名称/签名）、调用者/被调用者关系、（诸如函数起始/结束之类的事件的）时间戳、变量值、函数自变量、抛出/捕捉异常、锁争用以及其他信息。本领域技术人员理解，还可以通过插桩来获得许多其他类型的信息。

插桩的一个目的可以是：识别由应用执行的服务器请求中的慢函数。应用代码的插桩可以报告函数起始/结束事件。这些事件可以用于维持表示每个线程的活动插桩函数的插桩函数调用栈190。插桩函数调用栈可以包括针对插桩函数而选择的操作数据，例如函数识别以及函数起始事件的时间戳。该插桩函数调用栈与由应用运行时环境提供的调用栈分离且与之不同。插桩函数调用栈可以被用于将栈中包含的信息报告给用户的监视工具或报告模块容易地访问。除插桩函数栈外，代码插桩可以维持最近函数起始/结束事件的时间戳。维持该时间戳并不引起附加开销，这是由于无论如何都对起始/结束事件加时间戳。

系统100可以在服务器110上包括采样模块140。采样模块可以被配置为对服务器侧应用的应用线程进行采样。采样模块可以被配置为仅对特定线程进行采样。如上所述，可以针对每个线程维持活动插桩函数的插桩函数栈190。如果特定线程的插桩函数栈为空，则对于该线程而言不存在当前活动插桩函数。因此，可以通过仅对目前执行服务器请求的那些线程进行采样来减小开销。换言之，系统可以被配置为仅对具有非空插桩函数栈的那些线程进行采样。

插桩函数栈跟踪采样可以由专用采样线程来执行。采样线程可以被配置为周期性地唤醒和检查所有剩余线程以找到候选来采样。在上述一个方面，具有非空插桩函数调用栈的线程可以是采样的候选。在另一方面，为了限制采样并减小开销，采样线程可以被配置为分析特定线程或栈中的最后事件的时间戳。如果该最后事件是最近的，则系统可以认为采样不必要，这是由于插桩可能已经产生与线程行为有关的足够信息。如果该最后事件具有比预定时间段更久的时间戳，则可以认为采样有用。随着时间推移并且未通过插桩来报告事件，通过插桩而提供的信息可能不被认为足以提供如所期望那样多的细节或准确度。与确定事件是最近的或久远的相关的时间段可以相对于应用或特定函数的操作。在一些示例中，以秒或毫秒确定采样时间段可能是足够的。其他示例可能允许确定更大间隔的时间段或者可能需要更细地确定采样时间段（如微秒）。

如果在预定时间段内没有基于插桩的事件在线程上可见，则可以认为采样有用。在该示例中，采样可以填充由两个连续的基于插桩的事件创建的较大时间间隙。例如，性能分析师可能有兴趣知道在给定时间在特定线程中发生了什么，但是在一些情形中，在该时间段期间可能不存在得到该信息的插桩函数调用（尽管在该时间段之前和/或之后可能存在基于插桩的事件）。在该示例中，采样可以用于给性能分析师提供所期望的信息中的至少一些。

可以通过对置于与特定线程相关联的插桩函数栈上的最上方插桩函数进行分析，对线程是否是采样候选进行附加确定。如果已知最上方插桩函数具有较长等待时间，则可以跳过采样。此类函数的示例可以包括已知使线程休眠的函数或等待内部或外部事件的函数。如果已知函数具有较长等待时间，则可能不必要对线程进行采样，这是由于应用专员很可能知道在该时间线程正在做什么，并且该函数可能不需要针对附加细节进行采样。因此，系统可以跳过具有已知较长等待时间的函数的采样以减小开销。需要注意，可以在比程序员所期望的长得多的等待状态中延迟线程。然而，收集该线程的栈跟踪样本可能不会使应用专员更接近于找到延长的等待的根本原因。

所收集的栈跟踪样本和对应的时间戳可以附着至插桩函数栈上的最上方入口。换言之，样本和关联的时间戳可以附着至当前运行的插桩函数。由于不是所有函数都被插桩，因此实际运行函数可能不同。实际运行函数可以是从最上方插桩函数直接或间接调用的非插桩函数。

除了仅对执行服务器请求的线程进行采样以及仅对具有比预定时间段更久的时间戳的线程进行采样以外，该系统和方法还提供了减小开销的附加方式。可以对执行采样的频率进行限制以减小开销。如上所述，许多现代的采样系统以高达每秒100次或更多的频率进行采样。根据实施例，可以以低得多的速率对应用进行采样。在一个方面，该系统和方法可以以小于每秒100次的频率对应用进行采样。在另一方面，该系统和方法可以以小于每秒10次的频率对应用进行采样。先前的系统和方法已经使用较高采样频率来获得满意的应用性能数据。然而，这里所提供的插桩结合采样的使用可以提供在降低的采样频率下满意的应用性能数据。

系统100还可以在服务器110上包括用于报告通过如上所述的采样和插桩而获得的数据的报告模块150。报告模块可以被配置为将插桩函数操作数据和采样函数操作数据进行组合以形成统一的应用性能报告。该统一的应用性能报告可以由应用专员访问，以便分析应用性能和故障解决问题（例如延迟等）。报告模块可以包括被配置为对服务器请求调用树的表示进行构造以显示给应用专员的监视工具。

参照图2，利用指示所调用的函数的时间经过的时间线205示出了服务器请求调用树200（例如可以由应用专员查看）的示例。所示的框210、220的类型中的每一个表示应用的函数或方法。具有直线边缘的框210可以表示插桩函数，这是由于已知插桩函数的起始/结束时间。具有波浪线边缘的框220可以表示采样函数，这是由于可以仅估计或近似采样函数的起始/结束时间。在框中显示了示例函数名。在更小的框中已经使用三个点（“…”）来表示过于冗长而不能在框中显示的函数名。

需要注意，采样可以提供调用者/被调用者关系。换言之，采样可以提供与哪个采样函数被调用、哪个函数调用了采样函数以及哪些其他函数被采样函数调用有关的信息。当监视工具对服务器请求调用树的表示进行构造时，可以对附着至插桩函数的调用的栈跟踪进行分析。对于每次插桩函数调用，可以遍历栈跟踪，以在栈跟踪中定位该函数。由于采用了栈跟踪同时调用正在进行中，因此将找到该函数。换言之，监视工具可以针对采样跟踪对插桩函数栈进行分析，并使用调用者/被调用者关系将采样函数与插桩函数相关联，以便创建服务器请求调用树。

栈跟踪的处于插桩函数“之上”的部分可以用于创建对植根于插桩函数处的调用树的近似。与其他已知栈类似，插桩函数栈在后进先出（LIFO）的原理上进行操作。对栈跟踪的处于插桩函数“之上”的元素的引用指的是在插桩函数调用期间置于栈上从而处于插桩函数“之上”的栈帧。以这种方式，可以通过将图2颠倒过来并将最上方函数视为由栈的下方函数最后调用的函数来对栈进行视觉化。

在示例服务器请求调用树中，对采样函数起始/结束时间进行近似。该近似不具有函数的精确起始/结束时间。这些时间仅可以基于栈跟踪的采样时间戳和来自代码插桩的事件的时间戳而估计。因此，还估计通过采样而检测到的函数的等待时间。包括近似的节点在内的整个调用树可以由监视工具的图形用户界面组件显示。监视工具可以给用户供应视觉提示，以在通过插桩检测到的节点与通过栈跟踪采样检测到的节点之间进行区分，但是，整个树可以形成一个一致且概念上统一的实体。尽管所示的服务器请求调用树使用直线和波浪线边缘来在插桩和采样函数数据之间进行区分，但是还可以使用许多其他形式的区别。例如，采样函数框可以具有用于表示不精确起始/结束时间的边缘上的梯度，可以针对插桩和采样数据使用不同颜色，等等。

可选地，栈跟踪分析可以对在处于插桩函数“之下”的栈跟踪中出现的非插桩函数继续进行。与图2中呈现的仅在树的底部添加附加节点不同，这可以允许在通过代码插桩而创建的节点之间插入附加节点。

参照图3，示出了用于收集应用性能数据的方法300。可以对服务器上的服务器侧应用的所选择的函数进行插桩310，以获得插桩函数操作数据。服务器侧应用可以包括多个线程。可以维持320每个线程的插桩函数的调用栈。该栈可以由上述插桩模块维持。可以基于插桩的所选择的函数的线程栈来识别330该应用的执行服务器请求的线程。例如，插桩模块可以对在服务器请求的执行中调用的函数进行插桩。每个线程可以具有插桩函数的栈。如果线程的调用栈为空，则不存在活动服务器请求，并且无需对线程进行采样。如果调用栈不为空，则线程对服务器请求起作用并可以被采样。相应地，该方法还包括：对执行服务器请求的线程进行采样340，以获得采样函数操作数据。可以将插桩函数操作数据和采样函数操作数据进行组合350，以形成统一的应用性能报告。

根据实施例，插桩函数操作数据可以包括来自应用线程的函数的时间戳。此外，对于每个线程，记录最近事件（例如函数起始/结束）的时间戳。对应用线程进行采样还可以包括：对具有比预定时间段更久的时间戳的应用线程进行采样。对具有比预定时间段更久的时间戳的应用线程进行采样还可以包括：仅对具有比预定时间段更久的时间戳且已知已超过典型等待时间的线程进行采样。在形成统一的应用性能报告时，可以确定哪些服务器请求执行所耗费的时间大于预定时间量。可以对该信息进行标记以呈现给应用专员以供进一步查看。此外，如上述系统中所述，该方法可以包括：使用专用采样线程来对应用线程进行采样。

参照图4，示出了用于收集应用性能数据的方法400。可以对服务器上的服务器侧应用的所选择的函数进行插桩410，以获得插桩函数操作数据。插桩函数操作数据可以包括函数时间戳。服务器侧应用可以包括多个线程。可以维持420每个应用线程的插桩函数的调用栈。该栈可以由插桩模块维持。可以识别430具有比预定时间段更久的最近时间戳的线程。然后可以对所识别的线程进行采样440，以获得采样函数操作数据。可以将插桩函数操作数据和采样函数操作数据进行组合450，以形成统一的应用性能报告。

这里提出的用于收集应用性能数据的系统和方法将选择性插桩和栈跟踪采样进行组合。从栈跟踪采样获得的数据可以与从插桩获得的数据相结合并可以被呈现为每个所选服务器请求的一个调用树。

该系统和方法可以提供相对于现有系统和方法的许多优点。该应用性能数据收集系统和方法可以自动产生与长期运行的插桩函数有关的更多细节，即使这些更多细节是仅根据基于插桩的事件的调用子树的叶也是如此。因此，可能不需要性能分析师交互以得到该附加信息。该应用性能数据收集系统和方法能够消除以下需要：将附加插桩插入到应用以便识别为性能瓶颈负责的叶函数。通过将栈跟踪采样仅限于活动地执行服务器请求的那些线程以及现有插桩未产生足够数据时的那些情形，可以将组合方案的性能开销保持为显著低于现有技术方案的性能开销。可以利用非常低的开销来实现该系统和方法，从而使其对在生产环境中部署的应用的连续监视来说可接受。监视工具可以提供对引起问题的服务器请求的深度探讨能力，从而使应用专员更容易对性能问题进行故障解决。

尽管上述示例在一个或多个特定应用中示意了本发明的原理，但是对于本领域技术人员来说显而易见，在未运用发明能力的前提下以及在不脱离本发明的原理和概念的前提下，可以在实现的形式、使用和细节上进行多种修改。相应地，并不意在限制本发明，本发明仅由以下阐述的权利要求限定。

Claims (15)

1.一种用于收集应用性能数据的方法，包括：

对服务器上的服务器侧应用的预定函数进行插桩，以获得插桩函数操作数据，其中，所述服务器侧应用包括线程；

维持每个线程的插桩函数调用栈；

基于插桩的所选择的函数的线程栈的空虚度，识别所述应用的执行服务器请求的线程；

对执行服务器请求的线程进行采样，以获得采样函数操作数据；以及

将插桩函数操作数据和采样函数操作数据进行组合，以形成统一的应用性能报告。

2.根据权利要求1所述的方法，此外其中，所述插桩函数操作数据包括应用线程的时间戳，并且其中，对执行服务器请求的线程进行采样还包括：对具有比预定时间段更久的时间戳的应用线程进行采样。

3.根据权利要求2所述的方法，其中，对具有比预定时间段更久的时间戳的应用线程进行采样还包括：仅对具有比预定时间段更久的时间戳且已知已超过典型等待时间的线程进行采样。

4.根据权利要求1所述的方法，其中，形成统一的应用性能报告包括：确定哪些服务器请求执行所耗费的时间大于预定时间量。

5.根据权利要求1所述的方法，其中，对执行服务器请求的线程进行采样还包括：使用专用采样线程来对应用线程进行采样。

6.根据权利要求1所述的方法，其中，形成统一的应用性能报告包括：对部分地通过在采样栈跟踪中定位插桩函数而形成的服务器请求调用树进行构造。

7.根据权利要求6所述的方法，其中，对服务器请求调用树进行构造包括：对具有时间线、插桩函数的明确起始/结束时间以及采样函数的近似起始/结束时间的服务器请求调用树进行构造。

8.一种用于收集应用性能数据的方法，包括：

对服务器上的服务器侧应用的预定函数进行插桩，以获得包括函数时间戳的插桩函数操作数据，并且其中，所述服务器侧应用包括多个线程；

维持每个应用线程的插桩函数栈；

识别具有比预定时间段更久的最近时间戳的线程；

对所识别的线程进行采样，以获得采样函数操作数据；以及

将插桩函数操作数据和采样函数操作数据进行组合，以形成统一的应用性能报告。

9.根据权利要求8所述的方法，还包括：基于插桩的所选择的函数的线程栈的空虚度来识别所述应用的执行服务器请求的线程；以及对执行服务器请求的线程进行采样，以获得附加的采样函数操作数据。

10.根据权利要求8所述的方法，其中，对所识别的线程进行采样包括：仅对具有比预定时间段更久的最近时间戳且已知已超过典型等待时间的线程进行采样。

11.根据权利要求8所述的方法，其中，形成统一的应用性能报告包括：确定哪些服务器请求执行所耗费的时间大于预定时间量。

12.根据权利要求8所述的方法，其中，形成统一的应用性能报告包括：对部分地通过在采样栈跟踪中定位插桩函数而形成的服务器请求调用树进行构造。

13.根据权利要求9所述的方法，其中，对执行服务器请求的线程进行采样还包括：以小于每秒十次的频率对应用线程进行采样。

14.一种用于收集应用性能数据的系统，包括：

服务器，被配置为托管服务器侧应用；

所述服务器上的插桩模块，被配置为选择性地对所述服务器侧应用的函数进行插桩，以获得包括应用线程中的函数时间戳的插桩函数操作数据，并且还被配置为维持每个应用线程的插桩函数调用栈；

所述服务器上的采样模块，被配置为对所述服务器侧应用的应用线程进行采样，以获得采样函数操作数据，其中，所述采样模块被配置为基于通过插桩而获得的时间戳的寿命以及根据栈的空虚度而对哪些线程执行服务器请求的确定中的至少一个，对应用线程进行采样。

15.根据权利要求14所述的系统，还包括被配置为对部分地通过在采样栈跟踪中定位插桩函数而形成的服务器请求调用树进行构造的报告模块。