1952108 李凯胤 第三次任务 - XLab-Tongji/2021-WorkloadSimulation GitHub Wiki
WESSBAS:提取用于负载测试和性能预测的概率工作负载规范(一种基于会话的应用程序系统的模型驱动方法)
为了使用负载测试和基于模型的性能预测来评估应用系统的性能特征,需要工作负载规范。本文提出了一种方法(WESSBAS),旨在自动提取和转换工作负载规范。方法步骤:
- 首先,与系统和工具无关的领域特定语言 (DSL) 允许对基于会话的系统的工作负载规范进行分层建模。
- 第二,该 DSL 的实例是从生产系统的记录会话日志中自动提取的。
- 第三,将这些实例转化为负载生成工具和基于模型的性能评估工具的可执行工作负载规范。
通过使用负载测试工具Apache JMeter和Palladio组件模型,使用行业标准基准 SPECjEnterprise2010 和 1998 年世界杯访问日志进行评估后发现:
特定于工作负载的特征(例如,会话长度和到达率)和性能特征(例如,响应时间和 CPU 利用率)表明提取的工作负载与测量的工作负载高度匹配。
工作负载的规范和执行对于评估应用系统的性能属性至关重要。为了评估是否可以满足这些系统的非功能性性能要求,应用了负载测试和基于模型的性能评估方法。
在基于会话的应用系统中,尤其是基于 Web 的系统中,不同类型的用户以一系列相互依赖的请求与系统交互。这些交互的复杂性使工作负载规范成为一项艰巨的任务 。因此,手动创建这些工作负载规范非常耗时且容易出错。主要挑战之一是确保这些规范与实际工作负载相比具有代表性 。然而,工作负载的提取和规范是针对每种方法和每种工具单独完成的,这会导致额外的规范和维护工作。原因是这些方法没有集成,并且工作负载规范是在不同的详细级别上定义的。
为了应对这些挑战,本文介绍了 WESSBAS为基于会话的应用系统指定和提取代表性工作负载的方法。引入了一种称为 WESSBAS-DSL 的 (DSL),它支持对这些工作负载规范进行系统和工具无关的建模。记录的会话日志用作自动提取 WESSBAS-DSL 实例的基础。在创建这些实例的过程中识别出显示类似导航模式的不同客户组。此外,自动学习请求执行之间的请求间依赖关系(Guards 和 Actions (GaAs))。这些依赖来自这样一个事实,即请求的执行通常取决于先前请求的结果。概率和 GaAs 的组合需要计算条件概率,这些概率也是自动确定的。最后,生成可执行负载测试所需的协议信息。
例如,将生成的 WESSBAS-DSL 实例转换为通用负载测试工具 Apache JMeter 的可执行工作负载规范,包括在之前的工作中开发的 Markov4JMeter 扩展 。此外,DSL 实例被转换为代表架构级性能建模语言的 Palladio 组件模型的工作负载规范。我们专注于架构级性能模型,因为它们允许对系统架构、执行环境和工作负载规范进行单独建模 。
在系统生命周期中,共享一个通用工作负载模型对这两种方法都有几个关键的好处。例如,在开发期间,系统规范(例如,统一建模语言 (UML) 图)或来自专家访谈的信息是可用的,以便推导出关于工作负载概况的估计。这些知识可以在 WESSBAS-DSL 中编码,然后转换为性能模型以进行早期性能预测。一旦应用系统运行并且应该执行负载测试,负载测试的部分(例如,用户场景和工作负载强度)可以基于WESSBAS-DSL生成。因此,两种方法只需要创建一次工作负载。
为了评估新版本的性能特征,通常在测试系统上进行负载测试。这些测试期间使用的工作负载应该与生产系统的工作负载相当。这样做的优点是可以以更高的概率发现生产系统中也出现的瓶颈。因此,从生产系统中提取工作负载并将其转换为负载测试和性能模型的工作负载规范有两个好处。
-
第一个好处是减少了创建和指定负载测试和性能模型的工作量。由于生产工作负载会随着时间的推移而发生变化,因此可以通过一种简单的方式再次提取最新的工作负载,以减少维护工作。
-
第二个好处是支持软件开发和运营(DevOps)的集成。操作期间提取的工作负载可用于基于测量的 和基于模型的 持续集成方法,以检测开发期间的性能回归。
WESSBAS 方法也可用于验证性能模型。为了验证性能模型的正确性,将仿真结果与从系统导出的测量结果进行比较。为了这些结果的可比性,必须确保模拟结果和测量结果是通过应用相同的工作负载规范得出的。
WESSBAS 是第一种实现从运行时数据到可执行负载测试和性能预测方法的过程的方法。是用于自动提取基于会话的应用程序系统的概率工作负载规范,包括:
-
用于建模基于会话的概率工作负载规范的 DSL。
-
从记录的系统日志中自动提取 DSL 实例,包括导航模式的聚类。
-
从 DSL 实例到可执行的 JMeter 测试计划以及 Palladio 组件模型 (PCM) 的工作负载规范的转换。
-
这种方法的工具支持。
本文建立在工作负载规范的提取和规范方面的工作的基础上,包含以下主要改进和扩展:
- 工具支持将任意系统日志转换为所需的会话日志格式。
- GaAs 的自动学习和条件概率的计算。
- 生成可执行的负载测试(这包括协议信息的提取和集成)。
- 根据行业标准基准 SPECjEnterprise2010 和 1998 年世界杯访问日志对工作负载特征(例如,会话长度和操作计数)和性能特征(例如,响应时间和 CPU 利用率)进行综合评估。
相关工作负载规范(也称为工作负载描述)是由以下过程定义的:首先分析应用系统的用户交互(包括其他系统)的关键特征,并将这些特征建模为工作负载模型[17,26]。基于会话的系统的关键工作负载特征可以分为会话内指标[23]和会话间指标[23]。会话内指标描述了单个会话,包括会话长度、每个会话的请求数量和执行请求之间的思考时间。它们还将用户的行为描述为执行请求的序列。相反,会话间指标描述了每个用户的会话数量和随时间变化的活动会话数量(也称为工作负载强度)。我们将工作负荷描述的相关工作分为用户行为建模和工作负荷强度。本文还介绍了工作负载提取和性能模型工作负载建模的相关工作。
用户行为要么是基于脚本的,要么是使用分析模型来指定的。用固定的用户请求序列表示单用户场景的脚本由许多并发负载生成器线程执行。这些脚本非常容易记录和执行。然而,它们几乎没有提供改变工作负载特征的机会,例如不同的导航模式,因此往往不像实际工作负载那样具有代表性[21,35]。此外,正如Rodrigues等人[43]所研究的,使用这些脚本生成捕获和重放脚本的工作量要高于使用软件系统复杂性不断增加的分析模型的工作量。为了更有代表性地对用户行为进行建模,引入了分析模型。建模用户行为,特别是与网站相关的用户行为的一种流行方法是马尔科夫链[60]。Menascé等人提出了一种与我们的方法类似的方法[36,38]。
为了更有代表性地对用户行为进行建模,引入了分析模型。建模用户行为,特别是与网站相关的用户行为的一种流行方法是马尔科夫链[60]。Menascé等人提出了一种与我们的方法类似的方法[36,38]。基于马尔可夫链的HTTP服务器日志的图表(CBMGs)。他们应用k -均值聚类来为类似类型的用户识别cbmg。相比之下,在我们的工作中,采用了K-means算法的改进,称为X-means。Ruffo等人[44]提出了另一种使用cbmg生成代表性工作负载的方法。首先,从Web应用程序日志文件自动提取cbmg,然后从这些cbmg生成具有代表性的用户行为跟踪。基于这些跟踪,将使用性能测试工具httperf[39]的修改版本来生成Web流量。
已经证明这些模型可以用于工作负载生成。然而,它们的限制之一是不能处理前面提到的请求间依赖关系。在请求间依赖关系中,只有当商品已经添加到购物车中时,才能将商品从购物车中删除。为了克服这些局限性,Shams等人提出了一种基于扩展有限状态机(EFSMs)的工作负载建模形式化方法。EFSMs允许在会话中描述有效的用户请求序列。与基于马尔可夫链的方法相比,过渡是基于预定义的状态变量而不是概率的GaAs标记的。通过模拟efsms获得有效的会话。此外,还可以指定会话间和会话内的特征,例如考虑时间和会话长度分布以及定义请求类型的相对频率的工作负载混合。我们的工作结合了基于CBMGs和EFSMs[50]的建模方法。因此,在确保生成有效的用户请求序列的同时,启用了概率用户行为建模。
还有一些使用分析形式来定义工作负载模型的方法。例子包括面向形式的随机模型[21,35],概率时间自动机[1]或基于上下文的顺序动作模型[27]。建议的方法的一个限制是需要手工指定GaAs,因为它们不能自动从日志文件中提取出来。为了克服这一挑战,存我们扩展了Beschastnikh等人[10]的工作,基于从会话日志文件中挖掘的时态不变量,自动推导应用模型的GaAs(在4.4节详细解释)。
von Kistowski et al.[49]的著作中有一种侧重于工作量强度定义的方法。他们的LIMBO方法允许基于dsl的定义和提取随时间变化的和动态的负载配置文件和工作负载场景,包括季节模式、长期趋势、突发和一定程度的噪声。Herbst et al.[25]提出的工作提供了一种预测工作量强度的方法,在这种方法中,基于决策树和反馈周期选择合适的预测方法,以提高预测精度。WESSBAS专注于用户行为的规范,并为建模工作负载强度提供基本支持(参见第4.3节)。
工作负载的提取通常基于请求日志[38,51],设计规范,如UML图[20],或专家知识[4]。Costa等人[19]定义了一种与我们类似的方法,引入了一个抽象的中间模型,该模型定义了独立于所使用的技术的工作负载规范。这些作者关注于技术细节与测试场景的分离。UML图用作创建抽象中间模型的输入。这些模型实例被转换为负载测试工具Visual Studio load test和HP Loadrunner。由于UML图经常不可用或者不够详细,我们建议从日志文件中提取中间语言WESSBAS-DSL,同时考虑到协议信息和请求间的依赖关系
架构级性能模型[8,30,40]允许对使用行为进行建模,例如,基于UML形式。这些模型还允许工作负载强度的规范。以手工方式创建性能模型的工作大大减少了可以获得的任何好处。因此,提出了性能模型自动生成的方法[11,15]。这些方法关注于SUT的系统特定细节的自动提取,比如系统组件、组件之间的关系、组件分配和资源需求。然而,工作负载规范仍然必须手工建模,这需要性能专家的大量工作。
为了降低从架构级性能模型生成不同类型分析性能模型的复杂性,引入了PUMA[59]或Klaper[18]等中间语言。这些方法只关注基于模型的性能评估,不支持基于会话的应用程序系统的工作负载规范的定义。
Barna等人**提出了一种将基于模型的性能测试与基于web系统的负载测试相结合的方法[**6,7]。在他们的方法中,SUT被建模作为一个两层排队模型。然后,从软件和硬件瓶颈饱和的模型中推导出工作负载混合和工作负载强度。最后,导出测试用例并在SUT上执行。该模型是基于SUT的反馈回路自动调整的。与WESSBAS相反,用户行为是在事务级聚合的,例如购买事务,而不是单用户交互。
3.1节给出了理解论文所需的工作量说明形式的概述。基于本规范的The WESSBAS-DSL将在3.2节介绍。
本文描述的方法建立基于会话的系统生成概率和强度变化的工作负载之上。工作负载规范形式(工作负载模型)由以下组件组成:
-
应用模型,指定允许的服务调用序列和生成有效请求的特定于suit的细节。
-
行为模型,每个模型提供用户会话的概率表示,根据调用的服务和后续调用之间的思考时间作为马尔可夫链(?)。
-
行为组合,指定为在工作负载生成期间单个行为模型发生的概率。
-
工作负载强度,包括一个函数,指定工作负载生成执行期间并发用户数(可能变化)。
-
工作负载生成流程
WESSBAS-DSL表达工作负载模型的语言。在我们的方法中,WESSBAS-DSL被用作一种中间语言,一方面是构建特定于sut但与工具无关的工作负载模型,另一方面是生成负载测试工具和性能模型的相应输入。DSL结构提供了高度的灵活性和可扩展性。
关于WESSBAS-DSL中工作负载规范的类和关系,父类工作负载模型由应用程序模型、工作负载强度、行为混合和行为模型组成。
应用程序模型的表示对应于该组件的两层结构,包括用于会话层和协议层的EFSMs。会话层EFSM的状态,简称为应用程序状态,与服务和协议层EFSM相关联。服务是用例,例如,登录到一个系统或向购物车添加一个商品。协议层EFSM的状态与特定的请求相关联,这些请求可能是HTTP、Java、BeanShell、SOAP等类型;通过从公共基类派生额外的子类,可以轻松扩展当前支持的请求类型集。
行为模型被建模为马尔可夫链,每个(马尔可夫)状态也与一个服务相关联。因此,每个马尔可夫状态被精确地分配到会话层的一个应用程序状态。行为模型的转换被标记为概率和思考时间。目前支持的思考时间是高斯型的,也就是说,它们遵循一个正态分布,表示平均值和(标准)偏差值作为参数。退出状态是显式建模的,它们不与服务相关联,因为它们不向用户提供服务。每个行为模型都与定义Behavior Mix的相对频率相关联,并将其存储为专用类中的双精度值。这些频率包含在行为组合中。工作负载强度以字符串属性的形式存储在专用类WorkloadIntensity中,该类还可以作为所有类型的工作负载强度的基类。工作负载强度可以指定为定义可变工作负载的公式,也可以指定为固定工作负载的固定数字。
一句话描述:状态空间中经过从一个状态到另一个状态的转换的随机过程。该过程要求具备无记忆的性质:下一状态的概率分布只能由当前状态决定,在时间序列中它前面的事件均与之无关。
也就是说,马尔可夫链是一个随机系统,它必须满足两个条件:
系统任意时刻可以用有限个可能状态之一来描述; 系统无后效性,即某阶段的状态一旦确定,则此后过程的演变不再受此前各种状态及决策的影响。 在马尔可夫链的每一步,系统根据概率分布,可以从一个状态变到另一个状态,也可以保持当前状态。状态的改变叫做转移,与不同的状态改变相关的概率叫做转移概率。随机漫步就是马尔可夫链的例子。随机漫步中每一步的状态是在图形中的点,每一步可以移动到任何一个相邻的点,在这里移动到每一个点的概率都是相同的(无论之前漫步路径是如何的)
X(n) =X1(1) X2(2) ...Xk(n)- 概率向量的每个元素都是概率,并且元素之和为1。
- 系统的可能状态数有k个。
- 向量中各个元素分别表示表示第n次观测时第i个状态的概率
- X(0)被称为初始状态
尽管WESSBAS-DSL独立于特定的性能评估工具,但它包含生成基于所描述的工作负载建模形式的工作负载规范所需的所有核心信息
由于手动创建工作负载模型需要付出很大的努力,本节介绍了基于记录的系统日志自动提取WESSBAS-DSL实例的过程。这一节的其余部分细节六步程序获得一个WESSBAS-DSL实例,具体为:
- 从生产系统提取会话日志
- 基于聚类的行为组合提取
- 工作负载强度提取
- GaAs(guards and actions)的自动学习
- 条件概率计算
- 从Behavior Mix生成一个完整的WESSBAS-DSL实例
给定的WESSBAS-DSL实例可以转换为相应的JMeter测试计划。我们为众所周知的负载生成器Apache JMeter开发了一个名为Markov4JMeter的公开可用扩展,它允许我们定义和执行这些工作负载规范。JMeter支持生成各种类型系统的工作负载,而不限于基于web的系统。测试计划生成器读取一个序列化的WESSBAS-DSL实例,如4.6节所述,并构建一个进一步的XMI结构,可以由JMeter工具处理。
WESSBAS-DSL 概念到 (Markov4)JMeter 元素的映射
WESSBAS-DSL | Markov4JMeter 元素 |
---|---|
会话层 FSM | 马尔可夫状态(+传出转换) |
协议层 FSM | JMeter 元素(马尔可夫状态子元素) |
工作量强度 | MSC(会话到达控制器) |
行为模型 | MSC(频率表) → CSV 文件 |
行为组合 | MSC(频率表) |
输入参数 | 用户定义的变量 |
警卫和行动 | 用户参数 |
MSC马尔可夫会话控制器
- WESSBAS-DSL 中的会话层 EFSM 映射到 JMeter 中相应的一组马尔可夫状态。每个马尔可夫状态包括其单独的一组带有 GaAs 的传出转换,用于定义状态执行序列的有效性。对于每个保护和动作参数,都会创建一个所谓的用户参数。与用户定义的变量相反,用户参数特定于每个线程。用户参数和用户定义变量是 JMeter 提供的测试计划元素。生成的 JMeter 测试计划中马尔可夫状态的名称对应于 WESSBAS-DSL 实例中状态相关服务的名称。
- 工作负载强度作为公式字符串存储在测试计划(唯一)马尔可夫会话控制器的会话到达控制器子组件中。该控制器还包括一个行为混合频率表,以输入 WESSBAS-DSL 实例的适当值填充。
本节解释了 WESSBAS-DSL 实例到 Palladio 组件模型 (PCM) 工作负载规范的概念验证转换。第一给出了 PCM 的简短概述,然后描述了如何生成性能模型的系统特定部分。最后,描述了 WESSBAS-DSL 实例如何转换为 PCM 的工作负载规范。
PCM 是一种特定于领域的建模语言,它允许预测服务质量属性 (QoS),如响应时间、利用率和吞吐量。它由五种互补的模型类型组成。中心模型类型是Repository Model,它对软件组件、组件操作以及它们之间的关系进行建模。组件可以提供一个接口来向其他组件提供操作,或者需要接口来访问其他组件的操作。
由于我们提出的方法侧重于 PCM 工作负载规范的生成,因此模型的系统特定部分需要在单独的步骤中创建。由于手动建模需要太多的努力,因此可以使用从设计规范或正在运行的应用程序,中自动提取 PCM 实例的方法来生成 SUT 的系统特定部分。
我们使用 Brunnert 等人提出的方法。生成性能模型的系统特定部分。Java EE Servlet 过滤器用于收集有关对 Web 组件(即 Servlet、JavaServer Pages (JSP))的请求的数据。数据包括组件调用、它们之间的关系以及每个请求的 CPU 资源需求。然后,创建性能模型并集成每个组件调用的平均 CPU 需求。我们仅在对 Web 组件的请求级别上创建性能模型,而不会进一步拆分为其他组件,例如 Enterprise JavaBeans (EJB)。因此,生成的模型非常简单。对于每个模拟请求,平均测量的 CPU 时间将用于性能预测。
PCM 使用模型仅提供对复杂工作负载建模的基本支持:也就是说,使用模型不允许对任意使用流进行建模。每个元素只能有一个入边和一个出边。
我们不能将 WESSBAS-DSL 单独转换为使用模型。我们将部分工作负载规范生成到存储库模型中,使用这种方法我们不需要扩展 PCM 元模型。
WESSBAS-DSL 概念到 PCM 模型元素的映射
WESSBAS-DSL | PCM 模型元素 |
---|---|
会话层 FSM | 存储库模型(基本组件,RDSEFF) |
协议层 FSM | 不需要 |
工作量强度 | 使用模型(开放/封闭工作负载) |
行为模型 | 存储库模型(基本组件,RDSEFF) |
行为组合 | 使用模型(分支) |
输入参数 | 不需要 |
警卫和行动 | 范围 |
RDSEFF资源需求服务效果规范
每个结果分支转换指定调用概率并包含三个不同的操作:
- 此转换的思考时间按照 WESSBAS-DSL 中的规定建模,使用InternalAction作为具有均值和偏差的正态分布。
- 建模系统组件的匹配操作称为ExternalCallAction。
- 表示下一个马尔可夫状态的此行为模型组件的 RDSEFF 称为ExternalCallAction。
在评估期间,我们将我们提出的提取方法和工具应用于行业标准基准 SPECjEnterprise2010和 1998 年世界杯访问日志。这是对
- 提取的工作负载规范的代表性(定量)
- 方法和工具支持(定性)的实用性的调查
我们特别调查了以下五个研究问题,以评估我们提出的方法:
- *RQ 1:聚类结果与输入行为组合匹配的准确程度如何?*聚类的准确性是根据使用不同行为混合设置的基准运行的聚类的所有分类的错误分类会话的分数来评估的。要回答这个问题,需要分类会议。
- *RQ 2:聚类结果对已执行和预测工作负载的工作负载特征有何影响?*首先,提取 JMeter 和 PCM 实例。JMeter 测试计划在 SUT 上执行并模拟 PCM 实例。之后,集群对工作负载特征的影响评估基于:(i)三个基于会话的指标,即会话长度分布(每个会话的请求数)、会话持续时间和不同会话类型的数量;(ii) 基于请求的度量,即所有请求类型的相对调用频率。关于请求的到达率结论可以通过查看请求调用频率得出。
- *RQ 3:生产系统/SUT 的性能特征与使用生成和预测的工作负载的性能特征匹配的准确程度如何?*使用生成的和预测的工作负载的性能特征的准确性是根据 CPU 利用率、响应时间和堆使用情况进行评估的。堆使用仅针对测量和提取的工作负载进行评估,因为无法使用 PCM 对其进行建模和预测。
- *RQ 4:将不同的工作负载设置应用于提取的工作负载时,工作负载和性能特征的匹配准确度如何?*在测试环境中,评估不同工作负载设置(例如增加工作负载强度或不同行为组合)的影响通常很有趣。因此,我们会在更改这两个工作负载设置时评估工作负载和性能特征。我们使用从 RQ 2 和 RQ 3 中提取的工作负载并更改工作负载强度和混合。然后将再次将结果与从原始工作负载中提取的测量特征进行比较。
- *RQ 5:GaAs 对工作负载和性能特征有什么影响?*GaAs 的影响将通过使用和不使用 GaAs 执行工作负载来评估。
当 Workload Intensity 和 Behavior Mix 的设置发生变化时,提取的工作负载和模拟的工作负载的工作负载和性能特征与原始工作负载相当。
GaAs 可以对性能评估结果产生很大影响,具体取决于用户操作的控制流程。将条件概率与 GaAs 结合使用,工作负载特征类似于最初测量的工作负载特征。
在工作负载模型中引入 GaAs 的概念时,马尔可夫链的无记忆特性就丢失了。因此,为了确保保留从会话日志中提取的平均行为,我们计算并添加了条件概率到行为模型中。
为了获得具有代表性的工作负载规格,提出了 WESSBAS 方法,用于系统地提取和规范基于会话的系统的概率工作负载。我们还包括对负载测试工具 Apache JMeter 和性能模型 PCM 的转换。为了应对为不同的性能评估工具指定工作负载的挑战,我们首先引入了一种特定领域的语言DSL,它以通用的方式描述了工作负载的结构。我们演示了如何使用聚类算法识别具有相似行为模式的客户群。此外,以自动方式学习请求间的依赖关系并计算条件概率。这是第一种呈现从运行时数据到可执行负载测试和性能预测的整体过程的方法。
使用行业标准基准 SPECjEnterprise2010 和 1998 年世界杯访问日志的评估证明了所提出方法的实用性和高精度。此外,在 CPU 使用率、响应时间和堆使用率方面的性能特征与原始执行的工作负载相似,只有少数例外。该方法适用于所有基于会话的系统,并且不需要有关工作负载提取的详细知识。
在我们未来的工作中,我们将使用生成的性能模型研究负载测试用例的优先级和选择。此外,我们计划
- 以双向方式实现 WESSBAS-DSL 实例和 PCM 之间的转换。以双向方式测试 WESSBAS-DSL 实例和 PCM 的优点是在 PCM 内分析和选择测试用例,并且可以使用 WESSBAS-DSL 生成相应的负载测试脚本。
- 我们计划整合产生不同工作负载强度的方法