云环境下Web应用带宽资源预测与管理

孙天齐，胡建鹏,2，黄 娟，樊 莹

(1.上海工程技术大学 电子电气工程学院，上海 201620； 2.上海交通大学 计算机科学与工程系，上海 200240)

0 引言

如今越来越多Web应用都选择部署在云上[1]，而作为Web应用的管理人员,同时作为云用户，在保证服务质量(Quality of Service， QoS)的前提下，要尽可能降低云服务支出费用。带宽资源是云服务中一项主要支出项目，在按量付费的情况下，大多数云服务商对带宽资源的定价方式设定为：在超过一定带宽阈值后单位带宽价格提高几倍。对于一般的Web应用，带宽需求大部分时间都在一定的阈值范围内，但也会出现在特定的时间段内带宽需求增大，超出阈值，在这种情况下管理人员需要采取措施来进行带宽管理以保证QoS，且尽可能使花费最小。另外对于在何种负载强度下会出现带宽冗余同样是管理人员需要提前获取的知识，以便提前采取应对策略，因此对带宽资源管理的研究十分必要。

带宽资源管理包含以下两个重要方面：一方面是带宽需求预测；另一方面是带宽伸缩策略。带宽需求预测是在一定负载强度下预测系统可能需要消耗的带宽，对于基于Web的网络密集型系统来说，带宽资源总是成为影响性能的瓶颈[2]，而目前大多数资源管理研究只关注主要的计算资源，如CPU[3]、内存[4]、磁盘I/O[3]等，其中CPU最受关注，很少涉及带宽资源方面的研究。对于带宽伸缩策略，管理人员一般采取以下几种方式：带宽增减、虚拟机(Virtual Machine， VM)增减和服务分离与组合等。带宽增减是指直接增加或减少带宽，而系统本身不发生改变，这种方式操作简单；但是对于带宽需求较大的Web应用，增加带宽可能会带来较大的费用支出。虚拟机增减和服务分离与组合是在带宽增减的基础上另外执行的策略。虚拟机增加是将原有的系统复制到多个虚拟机副本，然后通过负载均衡控制各个虚拟机的带宽需求分配。该种方式可以使得单个虚拟机带宽需求上限低于阈值，从而降低带宽资源费用。虚拟机减少与虚拟机增加互为逆向操作。服务分离或组合是对系统结构的拆分或重组，分离是将原本部署在同一台虚拟机上的Web应用服务分离，比如将图片服务分离出来，移植到另一台虚拟机，这种方式和虚拟机增加类似，但Web系统结构会发生改变。组合则是将不同的服务整合到同一服务器。

针对各种计算资源预测的研究主要有以下几种方法：分析建模[3,5]、测试[6-7]、仿真[8]和机器学习[9-10]。黄翔等[11]提出一种Web应用自动建模方法用以性能剖析，他们采用基于概率的用户行为图模型描述负载，采用执行图描述事务之间的执行流程，并均采用分层排队网络构建模型，然后采用Kalman滤波进行服务时间估计；虽然该种方法可自动化建模，但其模型构建过程相对复杂。WISE(What-If Scenario Evaluator)方法[9]通过学习影响内容分发网络响应时间分布的因素之间相互关系构建贝叶斯网络，用以预测内容分发网络中配置和部署发生改变后产生的影响。尽管基于机器学习的方法适用于QoS的预测，且其中一些方法可不需要创建系统模型，但是机器学习方法只能学习过去出现的系统场景和配置，且需要收集足够多的数据用以训练。Kraken方法[6]通过不断将实时用户流量转移到一个或多个数据中心来进行负载测试，并分析单个系统和系统集群的行为以识别资源瓶颈。这种基于测试的方法可以提供可信的结果，但是该方法通常需要考虑额外的计算资源，另外其涉及大量的开发工作。Alam等[8]开发了一种用于Web系统性能管理的离散事件仿真工具；其仿真参数需要人工设置，且该方法仅适用于性能评估。

本文利用网络仿真工具模拟复杂网络传输过程，以适应带宽资源需求和QoS预测，普通仿真工具无法实现。上述研究中大部分负载模型采用概率图模型[12-13]来描述用户行为。传统事务型Web应用，包含了多种不同的交互事务，且用户行为由一系列会话，即对Web服务器的一系列请求(查询网页，下载图片等)组成，同时包含对不同页面的访问时间以及会话持续时间。由于用户行为的复杂性，导致概率图模型也变得复杂，这极大地增加了仿真的难度和时长。本文针对这种会话型Web应用，提出了一种简化的并行负载模型，极大地简化了用户行为描述，使得模型参数简化，并将此模型映射到网络仿真工具之上；同时本文采用自动化数据挖掘方法从Web应用访问日志中获取模型参数，进而通过仿真对不同负载强度下的带宽需求及响应时间进行预测。本文采用经典的TPC-W基准测试系统[14]对所提方法进行验证，并对不同带宽伸缩方案进行仿真评估，评估结果可为Web应用资源管理人员选择何种方案提供参考。

1 建模与仿真方法

1.1 Web服务建模与仿真框架

大型Web系统通常由一系列分布式服务组件组成。其中大部分包含多层次的体系结构，这些组件如用户接口(Web服务器)、业务逻辑(应用服务器)、数据存储(文件服务器)和数据库访问(数据库服务器)分别作为独立的模块进行维护。终端用户使用浏览器发送请求，这些请求通过网络传输到Web服务器。Web服务的建模与仿真不仅需要设计系统模型来描述系统架构，而且需要可以表示真实用户行为的负载模型；同时，基于TCP的复杂网络传输机制也需要在仿真框架中有所体现，因此，本文提出一个适用于Web服务的建模与仿真框架。

图1为本文系统模型的架构，包含从客户端到服务器端的所有子模型。本文通过负载模型挖掘用户行为和负载强度，通过Web服务模型获取各服务的属性，进而将模型映射到网络仿真工具相对应的物理模型中，模拟真实的网络传输过程。

图1 系统模型架构Fig. 1 Architecture of system model

图1中Profile模型是仿真工具中实现并行负载模型的组件，Application模型是仿真工具中模拟Web服务的组件，局域网(Local Area Network，LAN)模型用来模拟属于同一用户群组的客户端，Switch模型模拟交换机，各服务器模型对应真实的服务器。本文将Web服务定义为三元组(S，O，SG)，其中：S是指由Web应用提供的一系列服务；O表示嵌入在服务中的各种对象，每个对象具有两种属性，即类型(如Web页面、CSS (Cascading Style Sheets) 文件、JS (JavaScript) 文件、图片或子页面等)和该对象所占字节大小；SG(Service Group)是指具有相似性质服务的集合，每个服务可以根据其性质被分组到某一类SG中。另外本文将单次服务请求定义为六元组(t，u，s，o，b，rt)，其中：t表示服务请求时间，u表示请求用户，s∈S，o∈O，b表示该请求接收字节数，rt表示请求该服务的响应时间。Web服务模型参数将通过日志挖掘获得。

本文所提仿真方法包含4个主要步骤：1)建立负载模型；2)建立系统模型；3)挖掘访问日志以获得模型参数；4)运行仿真验证模型以及预测带宽需求和响应时间。由于负载特征的复杂性，本文提出了一种简化的并行负载模型，同时采用自动化日志挖掘方法，可以有效减少模型构建时间。

1.2 并行负载模型

本文负载模型的建立基于WESSBAS(Workload Extraction and Specification for Session-Based Application Systems)[12]方法，并在其基础上作出一系列修改，以满足对带宽资源的预测需求。在前期工作[15]中，我们设置了一个固定长度的时间窗口用以建模和仿真。时间窗口设定之后，模型的建立和仿真过程都要按照该时间窗口设置。这种设置有两个缺点：一方面时间窗口内出现的用户数量并不能代表并发的用户数量，对于负载强度的统计无法与基准测试系统统一起来；另一方面时间窗口对用户行为进行切片，破坏了用户行为的完整性，因此本文去除了时间窗口的设置。

大多数负载模型存在一个共同的问题，即请求的顺序和请求的数量由于遵循概率属性而难以控制，但是这个问题并不影响对于带宽需求的预测，因此本文假设在用户的会话中服务请求是无序的。本文使用多条并行子路径来代替对多个SG的串行请求序列，每一类SG的请求序列代表一条子路径，如图2所示。传统的负载模型中，多以串行请求路径来表征用户行为，一般含有三个参数，即会话长度、请求间隔矩阵和请求之间的转移概率矩阵，并且请求之间经常出现循环路径，这极大地提高了计算的复杂度。本文提出利用并行请求路径来表达用户行为，同样具有三个参数，分别为开始偏移时间、到达间隔时间和会话持续时间，但并行路径的设置避免了不同请求之间的相互转移，并且不需要控制循环请求次数。关于参数的设置，在实际情况中，由于需要描述用户会话的到达率，因此，本文添加开始偏移时间来确定用户何时发起第一次服务请求。到达间隔时间指两次请求之间到达的时间差，并且本文使用服务器端到达间隔时间来代替客户端用户的思考时间，因为所有的时间信息都是从服务器端日志中获取。

图2 并行负载模型Fig. 2 Parallel workload model

本文首先将具有相似行为模式的用户划分为若干群组(User Group, UG)，则负载模型可定义为行为组合(Behavior Mix，BM)与负载强度(Workload Intensity，WI)组成的二元组(BM，WI)。BM={B1，B2，…，Bn}，表示n个用户群组的行为组合，其中Bi是某个用户群组的服务请求行为，由多条SG并行路径组成，多种行为按比例混合成行为组合。WI表示负载强度，它代表在会话持续时间内出现的属于不同用户群组的用户数量。

由于带宽是一种并发消耗资源，不同于CPU的独占性，故本文采用并行请求路径来描述用户行为，忽略了不同请求之间的顺序，此种忽略对带宽消耗以及服务质量预测的影响不大。对于一个特定Web应用，用户对服务的请求将影响带宽需求。本文并行负载模型忽略了对请求顺序的控制，如图2所示，并行路径虽然分离了不同类型的服务请求，但在会话长度内，请求之间的到达间隔时间同样遵循串行路径中对应请求之间到达间隔时间的分布，使得对不同类型的服务独立请求，即在一段时间内对同一类型服务的请求时间较真实情况可能会提前或延后，但总请求数量变化不大。尽管这种设置会稍改变真实请求在时间上的顺序，但从全局来看，一段时间内的请求数量不会发生太大改变，使得本文所预测的全局性的带宽消耗量也基本不会改变。这样的设置同时使得负载模型变得相对简单，所需要的模型参数也得到简化。负载的生成需要用户行为的描述以及负载强度的定义。本文在仿真时，以用户数量来设置一定的负载强度，即可进行不同负载强度下带宽等相关资源的预测。在仿真完成后，仿真时间内总页面请求数、服务器端发送的总字节数和平均页面响应时间等可以作为主要的比较度量。

1.3 系统模型及其参数

对带宽需求和QoS的预测不仅需要表示真实用户行为的负载模型，而且需要构建系统模型来描述系统架构。描述系统架构需要基于组件的建模方法，目前已有很多体系结构建模语言和工具具备这样的能力，但是这些工具不能对如网络协议和包传输之类的网络问题进行建模，它们仅适合于非网络系统的建模或忽略网络资源的一些场景。一些常用的网络仿真工具，如NS- 2[16]和OMNET+[17]虽然具备网络建模功能，但并不适合对复杂的网络应用进行建模，而著名的OPNET[18]可以解决此问题。由于网络的复杂性，预测Web系统的QoS相对困难。由于网络拥塞控制和重传对响应时间有很大的影响，需要同时在应用层和网络层对系统进行细粒度建模，因此，选择一个特定的网络建模与仿真工具OPNET作为基础的建模与仿真工具，并将本文所提仿真框架映射到OPNET模型之上，这些模型的特征参数即代表用户行为和Web应用的特征，以实现对真实场景的模拟。

表1显示了本文所涉及的主要模型与参数的对应关系，这些参数可以通过日志挖掘获得或根据需要手动调节。

这些模型中的客户端和服务器端均包含物理层、网络层和应用层三层架构。在物理层，OPNET可以提供细粒度的建模来支持系统模型的构建；在服务器端，多层Web系统由交换机和服务器组成；在客户端，本文使用多个局域网模型来表示不同的用户集群。所有这些模型通过IP云和路由器模型连接起来。

表1 模型与参数对应关系 Tab. 1 Corresponding relationship between models and attributes

在网络层，所有客户端均配置HTTP 1.1协议。另外需要对TCP属性进行一些配置，OPNET提供不同操作系统(如Windows、Linux、IOS、Android)的默认TCP设置。TCP参数也可以根据需求自定义配置，包括接收缓冲区大小、协议特定算法、重传超时等。本文通过在Web访问日志中查询用户信息字段(包括操作系统和浏览器的信息)来决定客户端模型的TCP设置。在服务器端，服务器的TCP设置与真实实验环境所采用的TCP设置相同。带宽限制可以在服务器端和客户端之间的链路属性上指定。客户端和服务器端之间的距离会影响服务请求的响应时间，如果需要进行位置感知仿真，用户的位置信息可以通过Web访问日志中用户的IP地址匹配获得。本文采用TPC-W基准测试系统进行模拟实验，所有用户位置相同且已知，故可以直接设置客户端模型位置。

在应用层，使用标准的HTTP应用模型来表示位于不同Web服务器和文件服务器中的Web服务。每个Web服务包含两个主要参数，即到达间隔时间和页面属性。页面属性包含页面嵌入对象的数量和字节大小。本文使用OPNET的Profile模型来描述用户行为，其中需要指定开始偏移时间和会话持续时间。另外需要设置各局域网模型对应用户集群的用户数量，同时仿真开始前需要设置仿真时长，且需要根据具体实验设定。

1.4 从日志中挖掘模型参数

1.4.1 日志预处理

本文采用的日志为Web服务器访问日志，为服务器记录的标准日志，云用户可从服务器中获取。Web应用访问日志通常包含以下数据字段：请求的日期和时间、客户端用户IP地址和用户代理、请求服务的统一资源标识符(Uniform Resource Identifier，URI)、协议状态码、发送的字节、引用站点等。在原始日志中，每行记录表示一条请求，其可以是对Web页面、JS文件、CSS文件、图片或嵌入子页面等服务的请求。在预处理阶段，每一条记录将根据其所请求服务的类型被添加不同的标签。请求的日期和时间将合并在一起，并转换成时间戳格式。每个用户通过IP地址和用户代理来唯一标识，但本文中所采用的TPC-W基准测试实验为模拟用户访问Web应用，所产生的日志文件中用户IP信息均相同，故本文采用模拟浏览器ID来代替用户IP。另外，单个页面服务请求通常包含多个嵌入的对象，请求这些对象均会产生日志记录，本文将属于同一页面服务的请求添加同一页面标签。

1.4.2 服务请求的分组

许多服务请求在结构上非常相似。例如，某一用户在电子商务网站浏览两款不同的产品时，可能会导致两个请求具有不同的URI，但其响应结构是相同的。在该步骤中，将相似的请求分组到同一个SG中。分组完成之后，将会忽略一些总请求数较少并且对服务器负载贡献很小的SG，以简化后续参数挖掘和仿真实验过程。

1.4.3 参数挖掘

本文参数挖掘的过程是从处理之后的日志数据中提取参数的概率分布。本文主要采用两种方法来获取参数的概率分布。首先，本文使用分布拟合来估计参数概率分布。OPNET预先定义了多种刻画参数随机值的分布，本文将这些分布作为候选目标来拟合参数的概率分布，并通过拟合优度检验选择最佳模型。如果某一参数不能通过分布拟合来获得概率分布，本文采用OPNET中的概率分布函数(Probability Distribution Function，PDF)模型来定义，PDF允许对随机变化的值进行建模，因此能更真实地再现用户行为。本文所需挖掘的参数为并行负载模型以及Web服务模型所涉及的开始偏移时间、到达间隔时间、会话持续时间以及页面嵌入对象的数量和大小。

1.5 模型验证与仿真预测

在进行预测之前，需要通过一系列的仿真实验来验证模型的准确性和稳定性，即检验该模型预测的结果是否能表现出与原始日志数据相近的用户行为。模型的验证通过比较仿真结果和模拟实验日志数据的同一性和差异性，本文选择模拟实验设置的模拟浏览器数量作为负载强度，因为模拟浏览器数量即等同于用户数量，另外仿真时长设置与模拟实验相同，然后计算仿真结果中的平均请求数和服务器总发送字节，与相应的原始日志数据统计结果进行比较。

本文首先验证在负载强度变化情况下的模型准确性。模拟实验的原始日志文件将会分为两部分：一部分作为训练集和验证集；另一部分作为测试集。本文以页面平均响应时间(Average Response Time，ART)作为主要的QoS度量进行预测，响应时间是指用户从发出HTTP请求与接收到响应的最后一个字节之间的时间。

2 带宽需求预测实验

根据第1章的介绍，本文选取TPC-W基准测试系统进行实验来验证本文方法的有效性和准确性。

2.1 实验设置

本文采用威斯康星大学实现的Java版TPC-W基准测试系统[19]，该系统是一种服务器性能测试工具，它支持模拟用户浏览网页和在网站上处理订单等操作。本文所采用的TPC-W基准测试系统具体实现为一个电子商务网站和一个客户端，网站设置有两大类14种页面，测试时每个模拟用户在浏览一个页面后，会随机地进入到另外一个页面，直到一次会话结束。客户端模拟用户访问网站，并收集一些访问数据。访问模式分为三种，根据用户兴趣度而设定，分别为浏览型、商务型和购物型，同时客户端可以设置模拟访问人数、测试时间和用户思考时间等。本文模拟实验采用贴近真实场景的商务型访问模式。为了减少CPU资源竞争对服务质量预测的影响，实验中虚拟机的CPU利用率均控制在20%以下。

本文模拟实验选择在云服务器上实施。本文选择了多台阿里云服务器，分别位于上海和深圳，深圳地区云服务器作为TPC-W服务器端并采用CentOS 6.8操作系统，上海地区云服务器作为客户端并采用Windows Server 2008操作系统；同时在服务器端安装性能监控工具，实时获取服务器端性能数据。

服务器端带宽设置为5 Mb/s，第一次实验时间设置为5 h，模拟人数为30，该实验数据作为训练集和验证集，另外分别进行50人、70人、90人、100人、105人、110人、118人、122人、130人、140人和150人共11次实验作为测试集，每次实验时间为30 min，每次实验会得到客户端访问数据、服务器端性能监控数据和原始访问日志。

本文利用OPNET工具构建了包含一台服务器和一个局域网模型的系统架构，并通过路由器和交换机相连接。局域网模型代表同类型的用户集群，且被放置在上海区域，后续会根据实验结果调整位置，以满足响应时间预测要求。服务器模型放置在深圳区域，带宽限制为5 Mb/s，最后设置模型参数和负载强度以及仿真时长，负载强度和仿真时长与模拟实验设置相同。

2.2 实验结果及分析

2.2.1 参数挖掘

模型参数从30人实验日志中获得。通过数据处理发现用户访问的所有页面中其中7类页面总字节数占比96%以上，为了进一步简化模型，本文忽略剩余其他页面的影响。嵌入对象数量及大小均为固定值或离散分布，到达间隔时间均服从lognormal分布，如图3所示为Home页面到达间隔时间分布直方图。开始偏移时间和请求持续时间分布无规律，故均采用OPNET进行PDF建模。

图3 Home页面到达间隔时间 分布直方图Fig. 3 Distribution histogram of inter-arrival time of Home page

2.2.2 带宽需求及QoS预测

首先进行模型验证，即通过上述所建模型进行仿真，将仿真结果与训练集数据进行比较。本次仿真实验设置负载强度为30人，时长5 h，仿真过后比较总请求数量和服务器发送的总字节。

日志统计总请求次数为72 718，发送的总字节数为2 864 004 014 B,仿真结果总请求次数为67 783，发送的总字节数为2 890 102 556 B。可以看到，仿真结果都非常接近真实日志统计结果，服务器发送总字节相对误差更是在1%之内，而总请求数量相对误差稍大，为6.8%，主要是由于参数挖掘过程中忽略了对总字节贡献很小的页面和服务。结果说明训练的模型能很好地再现模拟实验中的用户行为。

其次测试模型预测能力。根据上述模型预测30人、50人、70人、90人、100人、105人、110人、118人、122人、130人、140人和150人的访问结果。负载强度均设置与模拟实验相同人数，仿真时长均设置为30 min。另外本文构建经典的线性回归和非线性回归预测模型对总请求次数和发送的总字节数进行预测，非线性回归采用三次函数拟合，输入为用户数，最后将三种预测结果与日志统计结果进行比较，如图4～5所示。

图4为总请求数预测结果对比，图4中可以看出，随着负载强度不断增大，网络仿真预测结果曲线的趋势和数值与日志统计结果相近，通过计算，其平均相对误差为4.6%，相对误差最小为1.5%，而线性回归预测虽然在负载强度较小时呈现好的预测结果，但当负载强度达到120人以上，预测结果仍呈上升趋势，而真实日志统计结果由于带宽利用率达到上限已呈现出下降的趋势。另外可以看到非线性回归预测结果较好。图5为服务器发送总字节数预测结果对比。同样非线性回归预测表现较好。对于线性回归预测结果，随着负载强度的增大，误差相比网络仿真预测越来越大，并且同样不会由于负载强度过大导致带宽利用率达到上限而出现与日志统计结果相似的趋势。通过计算，网络仿真预测的服务器发送总字节数平均相对误差为3.3%，相对误差最小为0.4%。结果说明网络仿真的预测能力较好，且优势明显，尤其对于发送总字节的预测更加准确，因此该方法很适合用于解决带宽资源相关的预测问题。另外从图中可以看到当人数为120～130时，预测结果出现下降的趋势，这主要是由于此时带宽消耗已超过5 Mb/s，出现了网络拥塞和延迟等待的现象。

通过实验和图4以及图5中的比较，相较于线性回归预测模型，网络仿真预测有以下几点优势：1)预测结果更加准确，特别是当负载强度过大导致带宽消耗达到上限时，其表现出与真实日志统计数据相近的结果；2)模型训练需要更少的数据集，网络仿真预测仅需要30人的实验数据作为训练集，而线性回归预测至少需要30人和50人实验数据作为训练集，甚至更多；3)网络仿真是对复杂网络传输的模拟，可以体现网络传输的完整过程，而线性回归预测仅是对数值的预测；4)网络仿真用一个模型一次实验即可得到对总请求数、服务器发送总字节数以及页面响应时间的预测结果，而线性回归需要构建三个模型，且需要分别进行计算。

图4 不同负载强度下总请求数预测结果比较Fig. 4 Prediction result comparison of total request number under different workload intensities

图5 不同负载强度下总发送字节数预测结果比较Fig. 5 Prediction result comparison of total sent bytes under different workload intensities

对于非线性回归方法，虽然其预测能力表现较好，但是该方法有两大弊端：1)其模型的训练需要30人至150人所有的实验数据，难以实现以少量数据建模预测未知结果；2)该模型不能适用于演化场景。当系统场景演化，带宽由5 Mb/s减小为4 Mb/s时，网络仿真模型只需要将带宽参数修改为4 Mb/s即可进行预测，而非线性回归模型则无法继续进行准确预测。图6所示为系统带宽为4 Mb/s时网络仿真和非线性回归两种方法对总发送字节数的预测结果，可以看到非线性回归预测出现很大误差，而网络仿真表现出较强的泛化能力，预测结果较好。综上本文选择网络仿真进行带宽需求及QoS预测。

图6 演化场景下不同负载强度下总发送字节数预测结果比较Fig. 6 Prediction result comparison of total sent bytes under different workload intensities in evolutionary scenario

接下来进行QoS预测，本文假设云服务商可以根据服务协议提供稳定的带宽资源，即承诺达到的可利用带宽均不低于用户购买量。根据1.5节本文将页面响应时间作为主要的QoS度量进行预测，且仅比较平均响应时间，即所有用户对某一页面请求的平均响应时间。本实验以Home页面作为研究对象，首先根据30人实验数据中所有用户对Home页面请求的平均响应时间，适当微调局域网模型的位置，使得仿真结果接近真实结果，然后进行50人、70人、90人、100人、105人、110人、118人、122人、126人和130人的预测实验，对比结果如图7所示。该图无法继续用回归方法来进行数据比较，因为低负载时，响应时间的均值波动不大，使用低负载数据进行训练并用回归的方法来预测平均响应时间不太可能，根本无法预知高负载时响应时间均值逐渐升高的状况。

图7 负载强度增加下响应时间预测结果比较Fig. 7 Prediction result comparison of response time with increased workload intensity

从图7可以看出，预测结果与真实结果相近，趋势相同，平均响应时间在120人以后均呈明显上升趋势，且上升越来越快。通过查看性能监控数据，发现在人数达到120至130之间时，带宽消耗已达到5 Mb/s，已经出现网络拥塞甚至延迟重传的现象，因此负载达到120人以后平均响应时间迅速上升。通过上述对模型的验证与测试实验，可以看到训练的模型预测结果具有较好的准确性，尤其对于带宽需求的预测表现出色，故可将该方法用于对带宽资源管理方案的评估。

3 带宽伸缩方案评估实验

为了进一步评估带宽伸缩策略，本文以页面平均响应时间为主要评价指标。根据30人负载实验获得的基础场景模型进行三种不同演化场景的仿真实验。

3.1 实验设置

三种演化场景实验分别为带宽增加、虚拟机增加和服务分离。三次实验均基于带宽消耗超过阈值，从2.2.2节可以看出当人数为130时已出现明显响应延迟，因此本文选取130人、140人和150人实验作为基准，进行带宽伸缩策略评估。本实验仍采用home页面平均响应时间作为评价指标。带宽增加场景即直接将带宽从5 Mb/s升到6 Mb/s，系统结构不发生变化；虚拟机增加场景为复制一个完全相同的虚拟机副本，带宽同样设置为5 Mb/s；服务分离场景为将图片服务器分离出来，服务器集群总带宽同样升到6 Mb/s，并根据页面图片对象所占总字节数比例进行带宽资源重组分配，以上场景均只需简单修改基础场景模型即可实现，而无需部署真实测试场景来评估这三种策略的好坏。

3.2 实验结果及分析

仿真实验分三次进行，负载强度分别为130人、140人和150人，仿真结果如表2所示。

从表2可以看出，相较于5 Mb/s带宽，采取带宽伸缩策略后平均响应时间均明显减小。可以看到增加系统副本策略平均响应时间最小，服务分离策略平均响应时间最长。虚拟机增加减轻了对单一服务器的负担，且总带宽更大；服务分离虽减轻了单一服务器的压力，但两服务器之间仍然存在依存关系。方案选择不仅需要考虑性能因素，且需要考虑成本。以阿里云服务器带宽包年包月计费标准[20]为例，单位带宽价格随着带宽的增加而增加，当带宽超过5 Mb/s时，超出部分单位带宽价格为原价格的3倍以上，因此最终选择何种策略需要综合考虑，比如要考虑增加服务器的费用。本文旨在提出进行带宽伸缩策略评估的方法，对于不同的Web应用、不同演化场景，均可采用该方法进行评估。

表2 带宽伸缩策略平均响应时间对比Tab. 2 Comparison of average response time under bandwidth scaling strategies

4 讨论

本文主要面向将Web应用部署在云上的云用户，而非云服务商，云用户不能获取其云上邻居(其他租户)的情况，因此本文并未考虑性能干扰等情况；但本文实验均在真实云环境中进行，若存在虚拟机之间的性能干扰，其影响必然会在日志中有所体现，而本文模型参数均来自于日志，出于此种考虑，本文暂不单独考虑云计算环境下的性能干扰等情况。

在本文所有实验中，为简化模型和处理过程，以及模型自身特点等原因，会导致实验结果出现一些偏差，进而影响最后预测结果的精度。具体如下：在参数挖掘和仿真实验过程中，忽略了对总发送字节数影响较小的用户类别和服务组；对参数进行分布拟合时均为近似拟合；另外采用OPNET中的概率分布函数定义参数分布时，对数据进行了分段平均。在实验结果的比较中，部分比较的结果是选取平均值进行比较，弱化了局部的数据特征。

5 结语

本文提出了一种基于网络仿真的带宽需求和QoS预测方法。其中包含一种简化的并行负载模型，将串行请求路径转化为并行路径，简化了建模过程；运用自动化日志挖掘方法提取模型参数，从而加快模型建立；并利用TPC-W验证了该方法的有效性和准确性，进一步评估了不同带宽伸缩策略的好坏，为Web应用管理人员提供参考。本文负载建模仅针对传统事务型应用，未考虑无状态的Serverless服务、微服务架构、批数据处理任务等负载建模，这些负载建模可以作为未来的研究内容。后续，将会对本文方法中的参数挖掘过程进一步简化并完善，并计划将本文方法应用到其他多种计算资源的研究中。