一种Web应用细粒度性能建模方法及其系统

本发明公开了一种Web应用细粒度性能建模方法及其系统。建模方法包括1)设定Web应用系统中间件平台的更新周期；2)提取一个更新周期内的Web应用系统中间件平台的运行数据；3)根据运行数据得出Web应用系统中间件平台的性能数据；4)根据当前性能数据生成并显示Web应用系统的分层排队网性能模型。本发明的建模系统包括状态更新模块、日志载入模块和分析模块。本发明的建模系统和方法无需人工参与，以Web应用平台监测到的运行数据和统计方式为基础，自动构造性能模型，并随系统状态变化而更新；所建造的模型粒度遵循标准的Web应用组件模型，可运用于多种Web应用平台；并真实反应Web应用系统被使用的情况。

技术领域

[0001] 本发明涉及Web应用性能建模技术，尤其涉及以分层排队网为基础，构建自适应的Web应用细粒度性能模型的建模方法及建模系统。

背景技术

[0002] 多层架构的Web应用已成为当前主流的网络应用，大量关键应用（电子银行、网上支付等等）采用Web应用实施，在一个较长时间内保障系统服务质量（QoS)十分重要。目前，惯用的做法是通过构造性能模型，对系统未来一段时间内的性能做预测，然后再以预测结果为指导，判断系统性能是否满足服务质量的要求。

[0003] 性能预测的基本原理是通过模拟真实系统排队等待、资源竞争的情况来分析系统 的性能。输入一般包括用户行为、组件的关联和资源消耗等数据，输出的性能数据包括吞吐率、响应时间和资源利用率等。

[0004] 根据模拟真实系统的抽象程度不同，预测方法可分为粗粒度和细粒度两类。粗粒度方法侧重于刻画服务器的行为，即研究服务器与服务器在宏观层面上的资源消耗。这种方法建模相对简单，适合于分析集群等环节下的多服务器的总体性能。但该方法并不考虑单个软件组件是如何消耗资源，以及组件和组件之间又是如何关联的。所以，预测结果不会反映软件组件的资源消耗，也就无法为发现软件结构上的性能问题提供有用的数据。而细粒度方法的基础是软件的执行结构图，即系统中重要组件间的调用与资源消耗。所以细粒度的方法除了可以预测出各个软件组件的性能，还可以预测出系统总的性能。

[0005] 但因为细粒度的方法需要了解软件的细节，所以建模过程相比于粗粒度方法也会复杂很多。因为此时，设计人员不仅需要详细了解软件的整体设计，还需要了解用户行为和资源的消耗，也就导致了构造一个细粒度模型的代价是非常昂贵的。

[0006] 已有一些研究意图降低构造Web应用性能模型的成本，他们或者针对其中某一个方面，或者属于粗粒度的方法，但是它们均未全面系统的为容量规划人员提供一种快捷高效的针对Web的性能建模方法。

[0007] William和Smith首先提出了一种基于软件性能工程的方法（C. U. Smithand L. G. Williams, Performance Solutions: A Practical Guide to CreatingResponsive, Scalable Software. Addison Wesley, 2002)将性能分析引入软件开发过程中。Gomaa和Menasce提出了基于“客户机/服务器”体系模式下的方法（H. Gomaa andD. Menascej Performance Engineering of Component-Based Distributed SoftwareSystems, Performance Eng.，R. Dumke et al.，eds. pp. 40-55，2001.)。该方法直接用类图和协作图描述组件间的交互形式分析生成扩展的排队网（EQN)模型。上述方法降低了性能模型构造的难度，但是正确的获得模型所需要的参数仍是一个难题，而且性能模型还需要服务时间、用户行为等其它参数。

[0008] Woodside等人提出了一种从软件设计环境中通过插入收集执行轨迹代码的方式自动生成 LQN 模型的方法（M. Woodsidej C. Hrischukj B. Selicj and S. Brayarovj AutomatedPerformance Modeling of Software Generated by a Design Environment, PerformanceEvaluation, vol. 45，pp. 107-123, 2001.)。此方法根据设计人员给定的抽象层度向源代码中插入代码，收集给定测试用例下软件所表现出的执行轨迹和资源消耗情况。但只适合于开发态的软件，并不适合于运行态的Web应用。

[0009] Yoshihira和J iang提出了一种基于监测数据发现系统中稳定关联关系的方法(Guofei Jiang, Haifeng Chen, Kenji Yoshihira, Efficient and Scalable Algorithmsfor Inferring Likely Invariants in Distributed Systems, IEEE TRANSACTIONS ONKNOWLEDGE AND DATA ENGINEERING, VOL. 19, NO. 11，NOVEMBER (2007) 1508-1523)。他们通过收集请求处理过程中组件对资源的消耗，分析出其中稳定的关联，然后依据建立的关联网络，分析系统的处理能力，发现瓶颈所在，进而做容量规划。但只能预测系统的可扩展性，而不能对系统性能进行预测。

[0010] Cherkasova等人提出了一种基于事务的容量规划方法（L. Cherkasova, KivancOzonat, Automated Anomaly Detection and Performance Modeling of EnterpriseApplications, ACM Transactions on Computer Systems, Vol. 27, No. 3, November 2009·)。与本研究相似，他们也将用户的一次HTTP请求看作一个事务。但他们的方法仍以请求为基本单元，本文则关注于组件，更有利于发现组件一级的性能问题。

发明内容

[0011] 针对上述问题，本发明依据Web应用系统及其平台所具有的特性，设计出一种基于监测数据自动构造性能模型的系统和方法。在本发明中，利用Web应用平台能收集到的日志信息，以统计方法为基础，通过轨迹跟踪，服务时间计算和用户行为模拟这几个方面的技术，透明的构造出一个可以能够细粒度预测系统性能的性能模型。

[0012] 本发明技术基础是Web应用平台系统所能提供的监测技术，获取主要包括三类日志数据，一是服务的执行轨迹(称之为调用链）；一是CPU总的利用率，具体指单个服务器的CPU利用率，如果服务器有多个核，则将所有核的利用率累加；一是用户使用系统的轨迹。具体来讲，为了响应用户发出的请求（完整的请求处理以及应答过程称为一个事务），Web应用会调用一系列的组件协作完成这一工作，而完成这一工作的组件的执行流程称为调用链，比如Servlet组件调用EJB组件，EJB组件又调用数据库等。用户使用系统的轨迹(称之为用户行为）则是指从用户第一次登陆应用，到最后一次访问应用之间的全部行为，一般包括了多次对系统不同页面的请求。支持这种监测的工具商业的和开源的都有很多，比如Oracle 的诊断框架（Weblogic Diagnostics Framework),开源的 InfraRED 工具（http://infrared, sourceforge. net),以及石开究论文（Curtis E. Hrischuk, Murray ffoodside.Trace-Based Load Characterization for Generating Performance Software Models.IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 25，NO. 1，JANUARY/FEBRUARY1999)等。因此，本发明将不涉及监测技术的说明，具体实现可以参照这些方法。

[0013] 使用本发明预测性能的过程，对系统维护人员来说是完全透明自动的，不需要人工干预。该系统启动之后，会自动的根据输入的日志信息，构造并更新性能模型。需要预测结果时，维护人员只需要调用分析功能，则可获得系统未来的性能。预测出的结果包括系统的吞吐率、响应时间、各软件组件的资源利用率和总的资源利用率，以及各硬件资源的资源利用率等。

[0014] 本发明的目的之一是提供一种Web应用细粒度性能建模方法，包括如下步骤：

[0015] I)设定Web应用系统中间件平台的更新周期；

[0016] 2)获取一个更新周期内的Web应用系统中间件平台的运行数据；

[0017] 3)根据运行数据计算Web应用系统中间件平台的性能数据；

[0018] 4)根据当前性能数据生成并显示Web应用系统的分层排队网性能模型。

[0019] 所述Web应用系统运行数据包括执行轨迹数据、CPU总的利用率和用户使用系统的轨迹数据。执行轨迹数据即系统为完成用户发出的请求而调用一系列组件的执行流程，又被称为调用链。

[0020] 所述性能数据包括执行图、部署状态数据、服务时间和用户行为模式图的派生向·量。部署状态数据是指Web应用系统中每个组件在服务器上的位置。服务时间指组件向外提供服务的某个功能服务（比如函数）实际需要的执行时间，不包含等待时间。

[0021] 所述执行轨迹数据用调用链表示，其中节点为组件，边为组件之间的调用关系，实线表示同步请求，虚线表示异步请求，编号表示调用的次数。

[0022] 通过合并一个事务的各调用链（即第一个节点相同的调用链）的对等节点形成总体执行路径得到一个事务的执行图，所述对等节点是指两个节点α和β满足以下条件：

[0023] 两个节点α和β表示同一个入口，且

[0024] 或者α的父节点和β的父节点是对等节点，且父节点到α和β的请求类型相同；

[0025] 或者α=β且α和β的父节点为空。

[0026] 其中，用户的一次HTTP请求为一个事务。

[0027] 通过分析执行轨迹上各组件所在服务器的IP地址，获得所述组件部署状态数据。

[0028] 采用Kalman滤波方式计算每个组件提供服务的执行时间得到所述服务时间。

[0029] Kalman滤波提供了一个在离散时间点估算不可观测状态X的通用方法。第k时刻状态Xk可以定义为一个线性随机差分方程：

[0030] Xk = AXh+BUh+Wh (I. a)

[0031] 第k时刻观察值总CPU利用率Zk定义为：

[0032] Zk = HXk+vk (l.b)

[0033] 其中A是从k-Ι时刻到k时刻状态转换矩阵，Uk^1是可选的控制参数，B是与控制相关的矩阵，Wk^1为测量误差，其协方差矩阵为Qk_lt) H是Xk到Zk的转换矩阵，Vk是测量误差，其协方差矩阵为Rk。

[0034] 将公式（I. a)和（I. b)做如下映射后可以得到k时刻各组件服务的服务时间：

[0035] Xk = Xh+Wh (2. a)

[0036] Zk = ΣΓ=ι k · xf + Vk (2. b)

[0037] 其中^ = Ixf ：tf ... ，表示k时刻η个组件中各组件服务的服务时间，Zk为总(PU利用率，t为各服务的吞吐率。根据CPU利用率法则，有公式（2.b)，即总CPU利用率等于各服务吞吐率与服务时间乘积的累加和。

[0038] 将上述两个公式进行迭代计算，从而获得服务时间。[0039] 将用户使用系统的轨迹数据转化为派生向量V的方法为：

[0040] 将公式

[0041 ]

[0042] 转换为矩阵形式：

[0043]

[0044] 其中Vi为每个事务在一次请求中被访问到的次数，V0=I ； I = (1,0, ... ,0)，

N +1且 Vn+1=1 ；

[0045] 求解矩阵形式公式对应的线性方程组，获得派生向量V。

[0046] 所述分层排队网性能模型的生成方法为：

[0047] 将单个执行图转换为初步分层排队网模型，其中，执行图的节点转换为LQN的入口（Entry);同一节点的服务合并为一个LQN模型的任务（Task)，生成单个服务的分层排队网模型；

[0048] 第二，在模型上附加各个组件的部署状态数据；

[0049] 第三，在模型上添加服务时间；

[0050] 第四，根据用户行为模式图的派生向量生成负载，将单个服务的分层排队网模型组合为完整的分层排队网性能模型。

[0051 ] 本发明的一个目的是提供一种Web应用系统细粒度性能建模系统，包括：

[0052] 状态更新模块，设定Web应用系统中间件平台的更新周期，依据每一更新周期内的Web应用系统的运行数据，计算得到性能数据；

[0053]日志载入模块，提取每一更新周期内的运行数据并载入状态更新模块；

[0054] 分析模块，依据当前性能数据，生成并显示Web应用系统的分层排队网性能模型。

[0055] 所述状态更新模块包括执行图分析器、部署分析器、服务时间分析器和用户行为简化器，

[0056] 执行图分析器利用执行轨迹数据计算Web应用系统完成一个事件的总体执行路径；获得所述执行图；

[0057] 部署分析器提取执行轨迹数据中的各组件在服务器上的位置数据，获得所述组件部署状态数据；

[0058] 服务时间分析器计算Web应用系统每个组件提供服务的执行时间，获得所述服务时间；

[0059] 用户行为简化器将用户使用系统的轨迹数据转化为用户行为模式图的派生向量。

[0060] 所述日志载入模块包括轨迹信息载入器、CPU利用率载入器和用户行为载入器，轨迹信息载入器载入执行轨迹数据；CPU利用率载入器载入系统服务器CPU的总利用率；用户行为载入器载入用户从登录直到退出过程中使用系统的轨迹数据。

[0061] 上述性能建模方法会随着系统的运行而周期性的更新，以保证性能模型的状态能随着系统的变化而变化。当维护人员期望预测系统未来性能时，可触发预测步骤，利用状态存储模块中的执行图、部署状态数据等性能数据获得未来的性能模型。本研究的性能模型选用分层排队网为基础（M. Woodside, “The Stochastic Rendezvous Network Modelfor Performance of Synchronous Client-Server Like Distributed Software，，，IEEETransactions on Computers, Vol. 44, No. I, January 1995，pp. 20-34),这种模型的最大优点是可以层次化的描述资源的使用情况，符合细粒度性能分析的需求。

[0062] 本发明提出了一种Web应用平台的性能建模系统和方法，其优点如下：

[0063] I)无需人工参与，自动构造性能模型；

[0064] 2)模型构造以Web应用平台监测到的运行数据和统计方式为基础，可自动随系统状态变化而更新；

[0065] 3)模型粒度遵循标准的Web应用组件模型，使用多种Web应用平台；

[0066] 4)模型将用户行为（即负载）简化为分层排队网模型所能接受模式，可真实的反应Web应用系统被使用的情况； [0067] 5)对Web应用系统的未来性能可提供软件组件、服务器节点和集群等多个层次的性能数据。

附图说明null实施方式

[0077] 下面结合附图及具体实施例说明本发明的技术方案。

[0078] 本发明以Web应用中间件所支持的标准组件模型为基础(如Servlet、EJB、SQL等)，通过监测到的运行数据和统计方法自动计算性能数据，并最终生成性能模型。主要监测数据包括调用链，CPU总的利用率和用户使用系统的轨迹。本发明主要涉及两个模块，一个是用于监测和处理数据的状态更新模块，一个是分析模块，能够利用检测到的运行数据建立性能模型，并预测Web应用的未来性能状态，是用户与维护人员交互的。

[0079] 状态更新模块主要负责监测Web应用的执行，通过分析日志信息，获得运行数据，实现构造执行图、获得部署状态数据，计算服务时间和简化用户行为这几项功能。另一方面，分析模块则在接受到维护人员的命令之后，通过载入最新的性能数据，构造出一个符合系统最新状态的性能模型，然后再计算分析出系统未来的性能。

[0080] 本发明利用Web应用系统中间件平台监测到的运行数据，获得性能数据并构建性能模型的总体方法为；

[0081] I)设定Web应用系统中间件平台的更新周期；

[0082] 2)获取一个更新周期内的Web应用系统中间件平台的运行数据；[0083] 3)根据运行数据计算Web应用系统中间件平台的性能数据；

[0084] 4)根据当前性能数据生成并显示Web应用系统的分层排队网性能模型。

[0085] 本发明的具体实施流程参见图I所示。其中的性能数据是联系数据处理与性能分析的纽带。当运行数据处理完之后，会作为性能数据保存起来，而当需要分析性能时，则会从中提取出来作为分析依据。

[0086] 具体的运行数据为执行轨迹数据、CPU总的利用率和用户使用系统的轨迹数据。性能数据包括执行图、部署状态数据、服务时间和用户行为模式图的派生向量。每个性能数据的获得在下文中结合本发明的系统详细说明。

[0087] 为实现以上流程，本发明的系统至少应包括

[0088] 状态更新模块，设定Web应用系统中间件平台的更新周期，依据每一更新周期内 的Web应用系统的运行数据，计算得到性能数据；

[0089]日志载入模块，提取每一更新周期内的运行数据并载入状态更新模块；

[0090] 分析模块，依据当前性能数据，生成并显示Web应用系统的分层排队网性能模型。

[0091] 但为了获得更好的发明效果，本实施例采用了如图2所示的总体结构。主要模块有初始模块、日志载入模块、状态更新模块、状态存储模块、分析模块五个部分。其中，状态更新模块是整个算法的核心，负责生产预测所需的关键数据。图中的小箭头表示从箭头的方向获取数据，如用户行为简化器从用户行为载入器获取数据。大箭头则表示执行的顺序。

[0092] 首先，初始模块主要负责确定待定监测的Web应用中间件平台。确定待定中间件平台的目的是为了便于日志载入模块正常工作，因为不同的中间件平台会存在些许差异，其上的监测工具也会有一定的差别，为了能获得所需的运行数据，需要针对性的做一点调整。但是这些方案的基本原理是一致的，而且如前所述不论是开源、商业，还是研究领域都有不少成果出现，所以这里并不具体介绍监测的方法。而所需的监测数据格式在日志载入模块中具体介绍。

[0093] 第二，日志载入模块主要负责将中间件监测到的运行数据载入到该发明的系统中，组织成本发明所需的格式，为状态更新模块提供数据。该模块包括了三个子模块：轨迹信息载入器、CPU利用率载入器、用户行为载入器。

[0094] 轨迹信息载入器主要负载载入调用链相关的数据，将其组织为本研究所需的格式。图3给出了本发明具体使用的一个事务的不同调用链结构。节点代表一个组件，边代表了组件之间的调用关系，实线表示同步请求，虚线表示异步请求，编号表示调用的次数。比如CO表示了处理事务的起始组件，rO表示用户请求数，rO_l表示CO组件调用Cl组件的次数。例如图3中的301表示用户请求了组件CO提供的服务，而组件CO又调用了组件Cl，组件Cl又先后调用了组件C2和C3 ；304则表示用户请求了组件CO提供的服务，而组件CO又异步调用了组件C4，组件Cl又调用了组件Cl。另外，轨迹中包含了各个组件所在服务器的IP ί目息。

[0095] CPU利用率载入器主要负责周期性载入服务器CPU的总利用率，本研究以秒为单位进行收集。每条记录的格式为：time: [vy νη]。每条记录首先由记录的时间开始,后面接一个记录各个核对应的CPU利用率。如果是传统的单核CPU，则数据元素个数为一，而如果是多核CPU，则数据元素个数与核数相同。

[0096] 用户行为载入器主要负责载入用户从登录直到退出过程中使用系统的轨迹。可以描述为用户行为模式图（D. Menasce, V. Almeida, A Methodology forWorkload Characterization of E-commerce Sites, Proceedings of ACM E-Commerce1999 (pp. 119-128)，即可表示为一个矩阵P= [Pi,」]的η X n的矩阵。Pi,」表示一个会话(一个用户的登录周期）中，事务i之后出现事务j的概率，O彡i，j彡N+1。其中，事务O标识会话开始，事务N+1标识会话终止。事务对应于一个暴露给用户的服务，通常是一个Web页面。

[0097] 第三，状态更新模块是本发明的关键，负责从载入的日志信息中统计分析出性能建模直接需要的数据。另外，状态更新模块确定状态更新周期的长短，确定之后按指定的周期更新状态。周期的长短可根据系统更新频繁度而定，比平均更新周期短即可。一般而言，将周期设为10-30分钟即可。状态更新模块由执行图分析器、部署分析器、服务时间分析器和用户行为简化器组成。

[0098] 执行图分析器负责从调用链(从轨迹信息载入器中读取）中分析出一个事务在总体上的执行路径，而不是某一次调用特定的调用链。因此，执行图分析器是通过合并一个事务的各调用链的对等节点从而形成总体执行路径，即一个事务的执行图。因为如果只是简 单的按节点合并图中组件，则会导致结构上的不一致。图3所示的调用链，如果只是简单的按节点合并则会出现C0->C4->C1->C3的路径，即组件CO调用了 C4，C4调用了 Cl，而Cl又调用了 C3。但实际并不存在该路径，导致不一致的原因在于C4->C1与C0->C1并不对等，如果合并过程中不做区分，则会出现实际并不存在的路径。

[0099] 为解决这个问题，本文定义了对等节点的概念。如果节点α和β是对等的，需要满足一下条件：

[0100] α和β表不同一个入口，且

[0101] 或者α的父节点和β的父节点是对等节点，且父节点到α和β的请求类型相同；

[0102] 或者α=β且α和β的父节点为空。

[0103] 对等节点的合并具体来说：用E(X)表示节点X的对等类,如果两个对等的节点在调用链中有α _> β，那么在合并后的事务执行图上有E ( α ) _>Ε ( β )。

[0104] 图4描述了图3的调用链合并后的事务执行图，其中保留了 C0->C1->C3和C0->C4->C1的调用关系，所以不会导致不一致。

[0105] 部署分析器主要分析调用链(从轨迹信息载入器中读取）中各组件的部署位置，即某个组件是部署在哪台服务器上的。这部分的信息仍然从轨迹监测信息中提取，通过分析轨迹上各个组件所在的物理设备的IP，从而获得组件的部署信息。

[0106] 服务时间分析器主要用于计算组件的服务时间，依赖于CPU利用率载入器、部署分析器和执行图分析器产出的数据。因为组件的服务时间很难精确的通过监测获得，因此只能通过其它可监测的数据计算出组件的服务时间。服务时间指组件向外提供服务的某个功能服务（比如函数)，实际需要的执行时间，不包含等待时间。本发明采用Kalman滤波的方式进行计算（R. E. Kalman, A New Approach to Linear Filtering and PredictionProblems, Transactions of the ASME-Journal of Basic Engineering, I960)。

[0107] 计算时需要使用到执行图和部署状态数据，用于确定各个服务器上的组件，以及这些组件的调用频率（即吞吐率，可由调用次数除以状态更新周期获得，以秒为单位)。同时，也会使用到CPU利用率的监测数据。下文将介绍一台服务器上的组件的服务时间的计

算方法。

[0108] Kalman滤波提供了一个在离散时 间点，估算不可观测状态X的通用方法。第k时刻状态Xk可以定义为一个线性随机差分方程：

[0109] Xk = AXh+BUh+Wh (I. a)

[0110] 第k时刻观察值CPU总的利用率Zk定义为：

[0111] Zk = HXk+vk (Lb)

[0112] 其中A是从k-Ι时刻到k时刻状态转换矩阵，Uk^1是可选的控制参数，B是与控制相关的矩阵，Wk^1为测量误差，其协方差矩阵为Qk_lt) H是Xk到Zk的转换矩阵，Vk是测量误差，其协方差矩阵为Rk。

[0113] 本发明将公式(I. a)和(I. b)做如下映射：

[0114] Xk = Xk-i+wk-i (2· a)

[0115] % = Σ?=ι k * Xi + Vk (2. b)

[0116] 其中4 = [λ-f X! ... 4]，表示k时刻η个组件中各组件服务的服务时间，Zk为总CPU利用率，t为各服务的吞吐率(组件的调用频率即吞吐率，可由调用次数除以状态更新周期获得，以秒为单位)。根据CPU利用率法则，有公式（2.b)，即总CPU利用率等于各服务吞吐率与服务时间乘积的累加和。所以H可以定义如下：

[0117] Hk= Lt1 t2…tn](2.c)

[0118] Kalman算法还需要一个初始值^和P0,其迭代过程如下：

[0119] I.使用Wh=O更新X的状态：

[0120]望;=Xu-x

[0121] 2.更新协方差矩阵P

[0122] Pfc = Pk-x + Qk

[0123] 3.计算 Kalman 增益：

[0124] Km = Pk-H^ + Rk) —1

[0125] 4.修正X的状态：

[0126] Xh = Xti + Kjl (Zif — HiiXji )

[0127] 5.修正协方差矩阵Pk:

[0128] Pk=(I^KkHk)Pk-

[0129] 初始值.¾和P。对Kalman滤波计算影响很小，可以设置为任何有理由的值。本文根据排队论的定义将初始值设置为= 王伟，张文博，魏峻，钟华，黄涛.一种资源敏感的Web应用性能诊断方法，软件学报，2010年21卷2期，pp. 194-208), rtt°为服务i的响应时间，即服务时间的等于响应时间乘以CPU空闲率；而P0 = *«5((%0)2, (X20)2(xS)2),由于各组件服务的服务时间是独立的,所以是对角矩阵。

[0130] 每次迭代必须确定Hk，Qk和Rk这三个矩阵。Hk可以通过调用链信息直接获得，即各个服务的吞吐率(一个采样周期内，服务被调用的总次数除以采样周期长度)。Qk表示每一次迭代中X变化的协方差矩阵，对于在线的系统通常无法获得，只能估计变化范围。但如果Qk太大将导致估算结果抖动过大，太小又会使结果变化细微，体现不出服务时间的波动。一个策略是将Qk设置为对角矩阵，且对角线元素为一个迭代过程中X变化的最大值的平方Qk

=diag( ξ 1； ξ 2，…，ξ η)，其中& = moxlsisk((x/-矿1)2)为每一次测量值的误差，即CPU总

的利用率的测量误差。本文认为CPU总的利用率的测量值误差很小，足以值得信赖，因此设Rk=O0迭代 过程中，第4步修正X的状态是服务时间估算的关键，该公式可以简化为Xmw=Xold+K-e的形式，即利用Kalman增益和误差e修正Xtjld的值.也就是说，随着新数据的不断收集，服务时间X可以在迭代计算的过程中不断的被更新，从而保证估算出的服务时间与实际服务时间的吻合。

[0131] 用户行为简化器主要负责将实际的用户行为（从用户行为载入器中读取）转化为分层排队网所能接受的形式。为了简化用户行为模式图，本发明引入了用户行为模式图的派生向量用其描述用户行为模式图的基本特征，即各事务在一个会话中被平均访问的次数，它与用户行为模式图中各事务被访问次数在概率上是相等的。

[0132] 设V表示用户行为模式图的派生向量，Vi表示每个事务在一次会话中被访问到的次数。如果假设％的次数是1，即事务开始的次数为I，那么各个事务被访问的次数可定义为公式（3)的形式，即各事务被访问的次数等于其前驱节点被访问次数与访问该节点概率的乘积。

N+1

[0133] Vi. = ^ V,. X Pi j J = I,... ,N + I (3)

/=0

[0134] 公式3可以写为矩阵形式：

[0135] Ψ =Pxp (4)

[0136]其中ί = =0W = 0，·.·，N + I且 VN+1=1，因为开始和结束事

务必然存在，且结束事务不会再访问其它事务。求解公式（4)对应的线性方程组，即可获得派生向量V。

[0137] 状态更新模块会以状态更新周期为间隔，周期性的执行，以更新性能数据。每次更新之后，性能数据都会保存在状态存储模块中，以便分析模块使用。

[0138] 第四，状态存储模块主要负责存储状态更新模块生成的最新状态，包括：执行图、部署状态数据、服务时间和用户行为，对应于状态更新模块相应子模块生成的结果。比如用户行为则是用户行为简化模块生成的用户行为模式图的派生向量。分析模块在收到维护人员的命令之后，会从该模块提取数据进行预测。

[0139] 最后，分析模块则负责根据状态信息生成性能模型，并调用其工具分析出未来的性能。该模块主要由性能模型构造器、性能分析模块、和显示模块组成。当发现状态存储模块存在性能数据时且被启动时，分析模块会调用各个子模块工作，将性能分析结果呈现给维护人员。否则，此时尚未完成一个采集周期，并未收集到运行数据，等待维护人员再次启动分析模块。

[0140] 性能模型构造器负责根据性能数据生成分层排队网性能模型，具体包括四个步骤：第一，根据单个执行图生成单个服务分层排队网模型；第二，附加上部署状态数据，确定各个组件的部署状态；第三，根据服务时间在性能模型的结构中填入服务时间这一参数；第四，根据用户行为模式图的派生向量生成负载，将单个服务的分层排队网组合为一个完整的分层排队网性能模型。[0141] 经过执行图分析器分析之后，会以事务为单元，生成各个事务的执行图。该执行图反映了事务在统计特征上的总体特征，可以直接转换为分层排队网模型（LQN)。转换规则是执行图中的节点（组件服务）转换为LQN的入口（Entry)，同时将同一个组件的服务合并为一个LQN模型的任务（Task)。图4为由执行图分析器处理图3所示的一个事务的不同调用链经合并对等节点后得到的执行图，转换成LQN模型如图5所示。

[0142] 附加部署状态数据的操作比较直接，只需在模型中将同一个硬件资源上的任务部署在同一个描述硬件资源的LQN模型上即可。图6给出了附加部署状态数据的一个例子。如果部署分析器分析出CO部署在ServerO服务器上，Cl和C2部署在Serverl服务器上，而C3和C4部署在Server2服务器上，则图5则会转化为图6所示结构。

[0143] 服务时间是分层排队网的一个关键参数。每个组件服务，即分层排队网的每个入口都有这一参数，表示该组件自身执行实际所需的时间，不包括自身和调用其它组件的等待时间。服务时间的估算由服务时间分析器完成。计算过程中，同一组件的不同服务，即LQN模型中不同任务的不同入口的服务时间将分别计算。但同一服务的不对等节点并不做区分，因为此时并不用关心组件之间的调用关系，只需要关心每个服务的服务时间即可。图·7给出了一个添加了服务时间参数的LQN模型的示例。图中Cl和C3任务具有两个入口，但是它们是同一服务的两个不对等节点，所以服务时间是一样的。

[0144] 用户行为模式图的派生向量不存在环，因此可以用LQN建模。图8给出了用户行为模式图的派生向量的LQN模板。任务EB模拟了一个用户，对应于LQN模型中模拟用户的特殊任务，可以采用开放和封闭两种方式生成负载（Franks, G. , Hubbard, A.，Majumdar，S.,Petriu,D. C. , Rolia, J. , ffoodside, C. M:A toolset for Performance Engineering andSoftware Design of Client-Server Systems. Performance Evaluation, Vol. 24, Nb. 1-2(1995) 117-135)。EB以派生向量V中的数值访问各个任务（从Tl到Tn)。这些任务是由执行图生成的LQN模型，但并不存在TO和Tn+1这两个的事务，因为它们只是开始和结束的标志。另外，如果同一任务分布在不同的事务执行图中，它们最后会合并为一个任务，但是入口并不合并，否则也会引起如何并调用链中所述的不一致问题。图中的每个事务，对应于一个类似于图8所示的执行图，但是相同的硬件资源最终会合并为一个。

[0145] 图9给出了一个简单的例子，描述了一个完整的LQN模型的样式。顶层任务EB代表用户，它会向应用服务器发出不同类型的请求。它的服务时间比较特殊，统计的是用户平均思考时间，而不是服务时间，因为用户操作的间隔是思考时间，而不是实际执行的服务时间。当用户请求到达负载均衡器后会按不同的比例转发给异构的应用服务器。应用服务器收到请求后会调用不同的数据库查询操作。当数据库查询完成后，再逐层释放嵌套等待，直到用户释放等待，一次请求结束。

[0146] 性能分析模块是一个求解分层排队网工具的计算器，可以通过分析工具LQNS和模拟工具 LQNSim 进行求解（Μ. Woodside and G. Franks, “Tutorial Introduction toLayered Modeling of Software Perfromance,>, http://www. see. carleton. ca/rads/lqns/lqn-documentation)。该工具的输入是一个分层排队网模型的性能模型,输出则是性能预测的结果。结果包含了系统总的响应时间、吞吐率、处理器利用率和单个组件的使用率、总执行时间等数据。依据这些数据，设计人员可以清晰地了解不同负载下系统的性能状况，再参照最终系统的需求说明，便可判断当前设计是否满足需求。特别是在有若干备选方案的情况下，通过比较预测结果，可以从中选择相对最优的方案。

[0147] 显示模块主要负责将预测的结果展示给维护人员，以图表的方式供维护人员以不同的形式分析比较系统的性能。图表显示主要负责将预测出的性能数据用折线图的方式显示响应时间、吞吐率、处理器利用率和单个组件的使用率和总执行时间等。横坐标为时间，纵坐标为上述各个性能数据，每种数据用一个直线图表示。

[0148] 总之，本发明以监测和统计的方式，为Web应用自动构造能适应系统变化的性能模型，从而预测出系统未来的性能表现。预测结果可以体现出系统不同层次和粒度的性能特征，比如表征出集群，集群中的节点，以及节点上的组件等几个层次上不同粒度的性能数据。为负载均衡策略调整，节点的供给与回收，瓶颈检测与定位，以及差异性的服务质量保障等控制技术提供量化依据。·