CN110651260A - 增强的组件延迟跟踪 - Google Patents

Abstract

用于跟踪组件延迟的系统、方法和软件技术。组件跟踪方法记录组件在促成针对服务的请求而运行时所述组件的开始时间和结束时间。另外，从属件跟踪方法记录也为促成所述请求而运行的组件的一个或多个从属件的开始时间和结束时间。可以根据每个组件的开始时间和结束时间以及其从属件的开始时间和结束时间来确定每个组件的延迟。在一些实现方式中，可以基于每个请求来分析组件延迟。

Description

增强的组件延迟跟踪

背景技术

在软件开发方面的延迟调查涉及找出程序或者其组件运行需要多长时间。这可能是开发过程的常规部分，或者可能是在程序或者其部分运行变得明显缓慢的情况下进行的。

开发人员有时通过检测可疑组件以记录其开始和结束时的时间戳来开始调查延迟的过程。检测代码能够帮助确定哪个组件可能是罪魁祸首，但是实施起来会是麻烦的并且难以反转。事实上，如果不被移除，检测代码自身甚至可能增加延迟。

更重要的是，获得关于给定组件的时间戳可能无法提供对组件内部正在发生的事情的足够细致的描述。作为示例，组件可能调用其从属件(dependency)，所述从属件是组件完成任务所依赖的其他资源。组件看起来缓慢的情况可能是该组件的从属件实际上导致了减慢。

为了减轻该问题，可以以更高的粒度级别来进一步检测程序，以便捕获组件的子组件以及从属件的延迟。遗憾的是，这种方案仅解决了必须初始地实施并且然后撤消检测代码的问题。

发明内容

在本文中公开了改善对软件组件的延迟跟踪的技术，使得可以分析组件延迟而不必检测个体组件。确切地说，在针对组件的入口点处以及在组件与其从属件之间的边界处调用跟踪方法。

在一种实现方式中，一种组件跟踪方法记录组件在促成针对服务的请求而运行时所述组件的开始时间和结束时间。另外，一种从属件跟踪方法记录也为促成所述请求而运行的所述组件的一个或多个从属件的开始时间和结束时间。可以根据每个组件的开始时间和结束时间以及其从属件的开始时间和结束时间来确定每个组件的延迟。在一些实现方式中，可以基于每个请求来分析组件延迟。

提供本概述是为了以简化的形式介绍一些概念，这些概念将在下文的具体实施方式中进一步描述。可以理解，本概述并不旨在标识所要求保护的主题的关键特征或必要特征，也并不旨在用于限制所要求保护的主题的范围。

附图说明

参考以下附图能够更好地理解本公开的许多方面。尽管结合这些附图描述了若干实现方式，但是本公开并不限于在本文中所公开的实现方式。相反，其目的是涵盖所有替代、修改和等同形式。

图1图示了在增强的组件延迟跟踪的实现方式中的操作环境。

图2图示了在实现方式中的延迟跟踪过程。

图3图示了在实现方式中的操作序列。

图4图示了在增强的组件延迟跟踪的实现方式中的另一操作环境。

图5图示了在实现方式中的操作场景。

图6图示了在实现方式中的操作场景。

图7图示了在实现方式中的操作场景。

图8A-8C图示了在实现方式中的延迟分析表。

图9图示了适合于实施在本文中所公开的组件延迟跟踪技术的计算系统，包括在附图中图示并且在下文的具体实施方式中讨论的任何架构、环境、元件、过程以及操作场景和序列。

具体实施方式

在本文中公开了用于跟踪和分析软件应用和服务中的组件延迟的技术。对于软件应用或服务中的给定组件，延迟可能由组件自己的业务逻辑或者从其从属件产生。在本文中所公开的跟踪方法对每个组件以及从属件的开始和结束加上时间戳，从而允许以片段(slice)来定义组件的延迟。片段或者是组件的延迟或者其从属件的延迟。

另外，延迟跟踪方法可以记录调用堆栈，使得延迟能够被归因于从属件或组件中的特定方法。当经由请求ID从组件的从属件中的所有从属件汇总对应的数据时，可以提供关于延迟如何累加以及哪些方法和从属件对延迟有贡献的全貌。利用调用堆栈来分析各片段将通知用户组件代码的哪一部分是成本高的。这可以辅助识别隐藏的从属件或代码问题，以及确定从属件调用是否必要和高效。可以在不同的构造之间对片段进行比较，以允许回归和代码修复。

图1图示了在增强的组件延迟跟踪和分析的实现方式中的操作环境100。操作环境100包括组件101以及其从属件103。操作环境100还包括由组件跟踪方法107和从属件跟踪方法109表示的各种跟踪方法。操作环境100可以在一个或多个计算系统上实施，其中，图9中的计算系统900是代表性的。

组件101表示可以在应用的上下文中由一个或多个处理器运行的软件应用的任何程序元素、模块、对象、类或其他这样的部分。组件101可以包括可以在组件的上下文中运行的各种方法、例程或其他子组件。另外，组件101包括边界点102和边界点104，其表示组件的边界。边界点102表示组件101的入口点。边界点104表示组件101可以从其中调用从属件103中的一个或多个从属件的出口点。

从属件103表示组件101可以调用并且在完成之后将编程控制返回给组件101的各种组件、服务或其他这样的资源。一些或所有从属件103可以在相对于组件101的相同运行时环境中本地执行，而其他从属件可以相对于组件101的运行时环境远程地执行。

组件跟踪方法107表示可以在针对组件101的入口点处调用以便对组件101的开始时间和结束时间加时间戳的方法。相反，从属件跟踪方法109也是由组件101调用的方法或函数，但是在组件101的出口处，用于对从属件103的开始时间和结束时间加时间戳。

组件跟踪方法107和从属件跟踪方法109被用于根据相对于图2所图示的跟踪过程200来跟踪程序组件的延迟。可以由从属件跟踪方法109访问调用堆栈113以获得与被跟踪的组件相关联的堆栈信息。调用堆栈113包括由帧115、帧117和帧119表示的各种帧，其中的每个帧可以保存描述在运行时环境中正在执行的组件和方法的信息。日志文件111表示可以对其写入和存储延迟信息的一个或多个文件、数据库或其他这样的数据结构。

跟踪过程200可以在组件101所属于的一个或多个软件应用、模块、组件或其他这样的编程元素的上下文中的程序指令中实施。程序指令引导运行代码以如下地操作的一个或多个底层物理或虚拟计算系统。

顺带地参考在图2中所图示的步骤，代码在组件的入口点处记录组件的开始时间，并且在将编程控制返回给调用其的组件或服务时记录组件的结束时间(步骤201)。代码还将时间戳记录在日志文件111中。另外，代码记录针对与每个时间戳相关联的组件的请求识别符(步骤203)。

主题组件可以在其操作期间调用一个或多个从属件。代码在日志文件111中记录每个从属件的开始时间和结束时间(步骤205)，并且还在日志文件111中记录与每个从属件相关联的请求识别符和调用堆栈信息(步骤207)。

利用在日志文件111中记录的针对每个组件和从属件的请求识别符、调用堆栈信息和时间戳，代码可以基于每个请求来识别针对每个组件的延迟(步骤209)。代码可以在组件每次运行时、周期性地或者以某种其他间隔来自动地计算延迟。在一些实现方式中，某种其他服务、实用程序或者其他这种程序可以执行识别给定组件的延迟的步骤。

图3图示了在一种实现方式中的操作序列300。在操作中，在满足请求的上下文中，组件101被另一组件、程序或服务调用。组件101立即调用组件跟踪方法107，并且将请求识别符传递给组件跟踪方法107。组件跟踪方法107在日志文件111中记录组件101的开始时间。

组件101继续运行其自己的逻辑，以促成所述请求。运行其逻辑需要花费时间，并且因此导致延迟。在逻辑的运行的某个时间点，组件101可以由逻辑来驱动以调用从属件。此时，组件101调用从属件跟踪方法109，并且将相同的请求识别符传递给从属件跟踪方法109。从属件跟踪方法109记录与请求识别符和调用堆栈信息相关联的从属件的开始时间。调用堆栈信息可以指示例如在从属件调用时正在运行组件101内的哪种方法或例程。

在这种场景中，从属件106被调用，其表示图1中的从属件103中的一个从属件。从属件106继续运行其自己的逻辑，在该逻辑完成时，其将程序控制返回给组件101。组件101再次调用从属件跟踪方法109，从而从属件跟踪方法109能够记录从属件106的结束时间。

一旦从属件106已经完成，组件101就继续运行其逻辑的其余部分。这可以涉及调用一个或多个其他从属件，在这种情况下，将针对调用109执行相同系列的步骤。组件101最终完成其例程，并且调用组件跟踪方法107。组件跟踪方法107记录组件101的结束时间，此时，组件101能够将控制返回给调用其的组件。

图4图示了在增强的组件延迟跟踪和分析的另一实现方式中的操作环境400。操作环境400包括与操作环境100相同的元素，其中添加了组件121。组件121表示可以为服务请求而调用的组件，在满足所述请求期间，组件101由组件121的内部逻辑来调用。可以用与组件101的边界相同的方式来检测组件121的边界(边界点122和边界点124)，使得其调用组件跟踪方法107和从属件跟踪方法109。

总体上，组件跟踪方法107和从属件跟踪方法109的实例跟踪组件121和组件101的开始时间和结束时间。与组件的每个实例相关联的请求识别符被存储在日志文件111中。这允许基于每个请求来分析组件101的延迟，因为组件101可以由组件121(或者任何其他组件)为促成其他请求而调用。

图5图示了在增强的延迟跟踪的一种实现方式中的操作场景500。操作场景500涉及组件501和组件511。组件501包括应用编程接口，通过所述应用编程接口可以与由API505表示的其他组件、应用或服务进行通信。组件511包括由API 514、API 515和API 516表示的若干应用编程接口。

组件501还包括代码部分503，代码部分503在组件501的入口处调用方法“DependencyBroker.Dispatch()”。组件511在其入口点处包括代码部分513，代码部分513也调用DependencyBroker.Dispatch()。类似地，组件501中的代码部分507在利用从属件时调用DependencyBroker.Invoke()。组件511中的代码部分517也调用DependencyBroker.Invoke()。

在操作中，API 505可以由某种其他组件、程序或服务来调用，此时，代码部分503调用DependencyBroker.Dispatch()来跟踪组件501的延迟。组件501的内部逻辑从时间tl-t2运行，此时，调用组件511的API 514。

此时，DependencyBroker.Invoke()被调用以跟踪API 514的开始时间和结束时间，其持续时间为t2-t5。另外，由组件511在其入口点处调用DependencyBroker.Dispatch()，使得可以跟踪组件511的实际延迟。组件511从t3-t4运行，并且记录了针对组件511的对应时间戳。

组件501的内部业务逻辑从t5-t6再次运行，此时，再次调用组件511，特别是API516。再次利用DependencyBroker.Invoke()来跟踪从属件的总体延迟，而组件511利用DependencyBroker.Dispatch()来跟踪其内部延迟，所述内部延迟可以包括其自身的从属件调用，这将由代码部分517来跟踪。

组件511从t7到t8第二次运行，此时，控制被返回到组件501。DependencyBroker.Invoke()记录API 516的结束时间，并且允许运行组件501的其余部分。组件501最终完成，并且其结束时间由DepdendencyBroker.Dispatch()来记录。

根据前述场景中可以意识到，能够通过考虑从属件调用的传输时间和从属件的实际延迟来计算运行每个组件的业务逻辑所需的实际时间。例如，组件101实际上从t1-t2、t5-t6和t9-10运行，或者总共仅运行3个时间单位。由组件进行的API调用使用4个时间单位，而组件511的业务逻辑仅使用2个时间单位。通过这两种延迟方法对组件和从属件的开始时间和结束时间两者的一致的记录允许以更高的粒度来查看延迟，而不是查看抵消在API调用中所涉及的延迟和在从属件中所涉及的延迟的组件501。

图6图示了在实现方式中的操作场景600。操作场景600包括组件601、组件611、组件621和组件631。组件601包括在调用API 605时调用组件跟踪方法的代码部分603以及在调用从属件时调用从属件跟踪方法的代码部分607。组件611包括在调用API 615时调用组件跟踪方法的代码部分613以及在调用从属件时调用从属件跟踪方法的代码部分617。组件621包括在调用API 625时调用组件跟踪方法的代码部分623以及在调用从属件时调用从属件跟踪方法的代码部分627。最终，组件631包括在调用API 635时调用组件跟踪方法的代码部分633以及在调用从属件时调用从属件跟踪方法的代码部分637。

在操作中，组件601可以由另一组件、应用或服务来调用，并且运行以促成请求(A)。代码部分603调用组件跟踪方法并且传递请求ID-A，使得能够与请求相关联地记录其时间戳。当组件601调用的组件611中的API615时，相同的请求ID-A被作为参数传递，允许代码部分613将请求ID-A传递给其自己的组件跟踪方法的实例。由代码部分607调用的从属件跟踪方法还能够记录与API 615相关联的相同的请求ID-A。

组件601还调用组件631中的API 635。代码部分607将请求ID-A传递给从属件跟踪方法，以便将其感知到的API 635的延迟记录在日志文件中。然而，代码部分633还将相同的请求ID-A传递给其组件跟踪方法的实例，从而能够与请求相关联地跟踪其自身的延迟。

可以将不同的请求(B)提交给组件621。代码部分623调用组件跟踪方法并且传递请求ID-B，以便能够与该请求相关联地跟踪组件621的延迟。组件621可以调用组件631中的API 635，并且通过这样做，将请求ID-B传递给从属件跟踪方法和组件631。由代码部分627产生的从属件跟踪方法与请求ID-B相关联地跟踪组件621的延迟，而由代码部分633调用的组件跟踪方法与请求ID-B相关联地跟踪组件631的延迟。

以这种方式，可以相对于不同的请求识别符对组件631的相对延迟进行分析，因为其延迟信息将与请求ID-A和请求ID-B两者相关联地被记录。

图7图示了在增强的延迟跟踪的实现方式中的另一操作场景700。操作场景700涉及组件A，组件A包括由代码部分701、代码部分703、代码部分705、代码部分707和代码部分709表示的各种代码部分。

代码部分701是针对组件A的入口点。当调用组件A时，代码部分701运行，包括通过调用组件跟踪方法来跟踪组件A的开始时间和结束时间。

在其操作期间的某个时刻，可以调用代码部分703中的方法A。方法A能够调用方法B或方法D，以及可能的其他方法，这取决于其自身的内部逻辑。代码部分705中的方法B可以调用代码部分707中的方法C。方法B也可以调用代码部分709中的方法D。

方法C和方法D表示从组件A到其他组件(诸如组件B和组件C)的出口点。在这种场景中，方法C可以调用组件B作为从属件。通过这样做，方法C利用从属件跟踪方法来记录从属件的开始时间和结束时间。方法D也可以调用组件B以及组件C作为从属件。通过这样做，方法D还利用从属件跟踪方法来记录从属件的开始时间和结束时间。

从属件自身也可以实施组件跟踪方法。组件B中的代码部分711在被方法C调用时调用组件跟踪方法。类似地，在组件B和组件C中的代码部分713和代码部分715在被方法D调用时分别调用组件跟踪方法。

记录的结果信息允许基于每个方法或基于每个从属件来分析组件A的延迟。利用调用堆栈，能够将每个调用堆栈的从属件调用汇总到平均异常值。由于记录的信息包括调用堆栈中的每种方法的延迟片段，因此能够为调用堆栈上的任意方法来计算非从属件延迟和从属件延迟。如果延迟是来自组件自己的代码而不是来自明显的从属件，则可能需要调用一些隐藏的从属件，或者代码自身可能效率不高。如果延迟是来自组件的从属件，则分析能够转向依赖的组件。

图8图示了在每个调用堆栈的非RPC延迟和RPC延迟相加(276个请求的总和以消除异常噪声)之后对Exchange Sync API的分析801，其中RPC调用是从属件调用。该分析表明，大多数非从属件延迟(663ms)来自WriteFirstBody。

由于根据非从属件延迟和从属件延迟计算可以使用请求识别符来跟踪组件内和跨组件的任何请求，因此能够采取两个动作。能够将延迟缩小为数个片段，以识别延迟来自何处。另外，能够通过识别调用模式和通过代码检查来确定从属件调用是否必要和高效。例如，在Exchange Sync API的图8B中的分析803中，示出了针对RPC延迟所来自的请求锁定等待时间。

图8C在分析805中示出了在CoreItem.Save()下三次调用了InternalGetAuditSubfolders。因此，这种从属件成为关于降低延迟和避免不必要的从属件进一步检查的良好候选。

图9图示了计算系统901，其表示其中可以实施在本文中所公开的各种应用、服务、场景和过程的任何系统或系统的集合。计算系统901的示例包括但不限于：服务器计算机、机架服务器、网络服务器、云计算平台和数据中心设备，以及任何其他类型的物理或虚拟服务器机器、容器以及其任何变型或组合。其他示例可以包括智能电话、膝上型计算机、平板计算机、台式计算机、混合计算机、游戏机、虚拟现实设备、智能电视、智能手表和其他可穿戴设备，以及其的任何变型或组合。

计算系统901可以被实施为单个装置、系统或设备，或者可以以分布式方式被实施为多个装置、系统或设备。计算系统901包括但不限于：处理系统902、存储系统903、软件905、通信接口系统907以及用户接口系统909。处理系统902与存储系统903、通信接口系统907和用户接口系统909操作性地耦合。

处理系统902从存储系统903加载并且运行软件905。软件905包括跟踪过程906，跟踪过程906表示关于前面的图1-8所讨论的过程，包括跟踪过程200。当由处理系统902运行以增强延迟跟踪时，软件905引导处理系统902针对至少在前述实现方式中所讨论的各种过程、操作场景和序列如在本文中所描述地操作。计算系统901可以可选地包括出于简洁目的未讨论的额外设备、特征或功能。

仍然参考图9，处理系统902可以包括微处理器以及从存储系统903取回并且运行软件905的其他电路。处理系统902可以在单个处理设备内实施，但是也可以跨在运行程序指令时协作的多个处理设备或子设备分布。处理系统902的示例包括通用中央处理单元、专用处理器和逻辑设备，以及任何其他类型的处理设备、其组合或变型。

存储系统903可以包括由处理系统902可读取并且能够存储软件905的任何计算机可读存储介质。存储系统903可以包括以用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术实施的易失性和非易失性、可移除和不可移除介质。存储介质的示例包括随机存取存储器、只读存储器、磁盘、光盘、闪存、虚拟存储器和非虚拟存储器、磁带盒、磁带、磁盘存储或其他磁存储设备，或者其他合适的存储介质，除了传播的信号。在任何情况下，计算机可读存储介质都不是传播的信号。

除了计算机可读存储介质之外，在一些实施方式中，存储系统903还可以包括计算机可读通信介质，在其上可以在内部或外部传输软件905中的至少一些。存储系统903可以被实施为单个存储设备，但是也可以跨相对于彼此并置或分布的多个存储设备或子系统来实施。存储系统903可以包括能够与处理系统902或者可能与其他系统通信的额外元件，诸如控制器。

软件905可以在程序指令中实施，并且在其他功能中，当由处理系统902运行时，可以引导处理系统902如关于在本文中所图示的各种操作场景、序列和过程所描述地操作。例如，软件905可以包括用于实施跟踪过程200的程序指令。

特别地，程序指令可以包括协作或者以其他方式交互以执行在本文中所描述的各种过程和操作场景的各种组件或模块。各种组件或模块可以被体现在编译或解释的指令中，或者被体现在指令的一些其他变型或组合中。各种组件或模块可以以同步或异步的方式，在单线程环境或多线程中串行地或并行地执行，或者根据任何其他合适的执行范例、变型或者其组合来执行。除了或者包括跟踪过程906，软件905可以包括额外过程、程序或组件，诸如操作系统软件、虚拟机软件或者其他应用软件。软件905还可以包括固件或者由处理系统902可执行的一些其他形式的机器可读处理指令。

通常，软件905当被加载到处理系统902中并且运行时，可以将总体上合适的装置、系统或设备(其代表为计算系统901)从通用计算系统转换为专用计算系统增强组件延迟跟踪。实际上，在存储系统903上的编码软件905可以转换存储系统903的物理结构。物理结构的具体转换可以取决于该描述的不同实现方式中的各种因素。这样的因素的示例可以包括但不限于用于实施存储系统903的存储介质的技术以及计算机存储介质被表征为主要存储还是次要存储，以及其他因素。

例如，如果计算机可读存储介质被实施为基于半导体的存储器，则软件905当在其中编码程序指令时可以转换半导体存储器的物理状态，诸如通过转换晶体管、电容器或构成半导体存储器的其他分立电路元件的状态。关于磁性或光学介质，可能发生类似的转换。在不背离本描述的范围的情况下，物理介质的其他转换是可能的，其中，提供前述示例仅仅是为了促进本讨论。

通信接口系统907可以包括允许通过通信网络(未示出)与其他计算系统(未示出)进行通信的通信连接和设备。一起允许系统间通信的连接和设备的示例可以包括网络接口卡、天线、功率放大器、RF电路、收发机以及其他通信电路。连接和设备可以在通信介质上通信以与其他计算系统或系统网络交换通信，例如金属、玻璃、空气或者任何其他合适的通信介质。前述介质、连接和设备是公知的，并且在此无需详细讨论。

用户接口系统909是可选的，并且可以包括键盘、鼠标、语音输入设备、用于从用户接收触摸手势的触摸输入设备、用于检测非触摸手势和用户的其他运动的运动输入设备，以及能够从用户接收用户输入的其他可比较输入设备和关联的处理元件。用户接口系统909中还可以包括输出设备，诸如显示器、扬声器、触觉设备以及其他类型的输出设备。在一些情况下，可以将输入设备和输出设备组合在单个设备中，诸如组合在能够显示图像并且接收触摸手势的显示器。前述的用户输入设备和输出设备在本领域中是公知的，并且在这里不需要详细讨论。

用户接口系统909也可以包括关联的用户接口软件，所述用户接口软件能由处理系统902运行以支持上文所讨论的各种用户输入设备和输出设备。用户接口软件和用户接口设备可单独或彼此结合以及与其他硬件和软件元件结合，可以支持图形用户接口、自然用户接口或者任何其他类型的用户接口。

在计算系统901与其他计算系统(未示出)之间的通信可以在一个或多个通信网络上并且根据各种通信协议、协议组合或者其变型发生。示例包括内联网、互联网、局域网、广域网、无线网络、有线网络、虚拟网络、软件定义的网络、数据中心总线、计算底板或者任何其他类型的网络、网络的组合或者其变型。上述通信网络和协议是公知的，无需在此详细讨论。然而，可以使用的一些通信协议包括但不限于互联网协议(IP、IPv4、IPv6等)、传输控制协议(TCP)、用户数据报协议(HDP)以及任何其他合适的通信协议、变型或者其组合。

在交换数据、内容或任何其他类型的信息的任何上述示例中，信息的交换可以根据各种协议中的任一种发生，所述协议包括FTP(文件传输协议)、HTTP(超文本传输协议)、REST(表示状态传输)、WebSocket、DOM(文档对象模型)、HTML(超文本标记语言)、CSS(级联样式表)、HTML5、XML(可扩展标记语言)、JavaScript、JSON(JavaScript对象符号)和AJAX(异步JavaScript和XML)，以及任何其他合适的协议变型或其组合。

在附图中提供的功能框图、操作场景和序列以及流程图表示用于执行本公开的新颖方面的示例性系统、环境和方法。尽管为了简化说明的目的，在本文中包括的方法可以是功能图、操作场景或序列或流程图的形式，并且可以被描述为一系列的动作，但是应当理解和意识到，这些方法不受动作次序的限制，因为一些动作可以据此以与在本文中所示和所述的动作不同的次序和/或与其他动作同时发生。例如，本领域技术人员将理解并了解，方法可以替代地表示为一系列相互关联的状态或事件，诸如在状态图中。此外，对于新颖的实现方式，可能不需要方法中示出的所有动作。

在本文中所包括的描述和附图描绘了特定的实现方式，以教导本领域技术人员如何制作和使用最佳选项。为了教导发明原理，已经简化或省略了一些常规方面。本领域技术人员将意识到，根据这些实现方式的变型落入本发明范围内。本领域技术人员还将认识到，上述特征可以以各种方式组合以形成多种实现方式。结果，本发明并不限于上文所描述的特定的实现方式，而是仅由权利要求书以及其等同物来限定。

Claims (14)

1.一种计算装置，包括：

一个或多个计算机可读存储介质；

处理系统，其与所述一个或多个计算机可读存储介质操作地耦合；以及

被存储在所述一个或多个计算机可读存储介质上的用于跟踪组件延迟的程序指令，所述程序指令当由所述处理系统读取和运行时引导所述处理系统至少用于：

记录为促成针对利用组件中的至少一些组件的服务的请求而运行的所述组件的开始时间和结束时间；

记录也为促成所述请求而运行的所述组件的从属件的开始时间和结束时间；以及

记录针对与所述组件中的每个组件和所述从属件中的每个从属件相关联的服务的所述请求中的每个请求的标识，以考虑在给定请求的上下文中至少基于给定组件的开始时间和结束时间以及所述从属件中由所述给定组件调用的那些从属件的开始时间和结束时间，来基于每个请求分析所述组件中的每个组件的延迟。

2.根据权利要求1所述的计算装置，其中，所述程序指令还引导所述处理系统在针对所述组件中的每个组件的入口点处调用组件跟踪方法，以便记录所述给定组件的开始时间和结束时间。

3.根据权利要求2所述的计算装置，其中，所述程序指令还引导所述处理系统在所述给定组件与从属件之间的边界处调用所述组件中的每个组件的从属件跟踪方法，以便记录所述从属件的开始时间和结束时间。

4.根据权利要求1所述的计算装置，其中，所述程序指令还引导所述处理系统记录与所述组件的所述从属件的所述开始时间和所述结束时间相关联的调用堆栈。

5.根据权利要求4所述的计算装置，其中，所述延迟跟踪服务引导所述处理系统记录与所述组件的所述开始时间和所述结束时间相关联的所述请求的标识。

6.根据权利要求1所述的计算装置，其中，所述从属件包括远程过程调用。

7.根据权利要求6所述的计算装置，其中，所述服务包括用于在电子邮件存储库中查找电子邮件的查找消息服务。

8.一种用于分析组件延迟的方法，包括：

记录为促成针对利用组件中的至少一些组件的服务的请求而运行的所述组件的开始时间和结束时间；

记录为促成所述请求而运行的所述组件的从属件的开始时间和结束时间；以及

记录针对与所述组件中的每个组件和所述从属件中的每个从属件相关联的服务的所述请求中的每个请求的标识，以考虑在给定请求的上下文中至少基于给定组件的开始时间和结束时间以及所述从属件中由所述给定组件调用的那些从属件的开始时间和结束时间，来基于每个请求分析所述组件中的每个组件的延迟。

9.根据权利要求8所述的方法，还包括：在针对所述组件中的每个组件的入口点处调用组件跟踪方法，以便记录所述给定组件的开始时间和结束时间。

10.根据权利要求9所述的方法，还包括：在所述给定组件与从属件之间的边界处调用所述组件中的每个组件的从属件跟踪方法，以便记录所述从属件的开始时间和结束时间。

11.根据权利要求9所述的方法，还包括：记录与所述组件的所述从属件的所述开始时间和所述结束时间相关联的调用堆栈。

12.根据权利要求8所述的方法，其中，所述从属件包括远程过程调用。

13.根据权利要求12所述的方法，其中，所述服务包括用于在电子邮件存储库中查找电子邮件的查找消息服务。

14.一种或多种计算机可读存储介质，在所述计算机可读存储介质上存储有用于跟踪组件延迟的程序指令，所述程序指令当由处理系统读取和运行时引导所述处理系统至少用于：

记录为促成针对利用组件中的至少一些组件的服务的请求而运行的所述组件的开始时间和结束时间；

记录也为促成所述请求而运行的所述组件的从属件的开始时间和结束时间；以及

记录针对与所述组件中的每个组件和所述从属件中的每个从属件相关联的服务的所述请求中的每个请求的标识，以考虑在给定请求的上下文中至少基于给定组件的开始时间和结束时间以及所述从属件中由所述给定组件调用的那些从属件的开始时间和结束时间，来基于每个请求分析所述组件中的每个组件的延迟。

Images