云環境下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的預測不僅需要表示真實用戶行為的負載模型，而且需要構建系統模型來描述系統架構。描述系統架構需要基于組件的建模方法，目前已有很多體系結構建模語言和工具具備這樣的能力，但是這些工具不能對如網絡協議和包傳輸之類的網絡問題進行建模，它們僅適合于非網絡系統的建?；蚝雎跃W絡資源的一些場景。一些常用的網絡仿真工具，如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種頁面，測試時每個模擬用戶在瀏覽一個頁面后，會隨機地進入到另外一個頁面，直到一次會話結束?？蛻舳四M用戶訪問網站，并收集一些訪問數據。訪問模式分為三種，根據用戶興趣度而設定，分別為瀏覽型、商務型和購物型，同時客戶端可以設置模擬訪問人數、測試時間和用戶思考時間等。本文模擬實驗采用貼近真實場景的商務型訪問模式。為了減少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帶寬，采取帶寬伸縮策略后平均響應時間均明顯減小?？梢钥吹皆黾酉到y副本策略平均響應時間最小，服務分離策略平均響應時間最長。虛擬機增加減輕了對單一服務器的負擔，且總帶寬更大；服務分離雖減輕了單一服務器的壓力，但兩服務器之間仍然存在依存關系。方案選擇不僅需要考慮性能因素，且需要考慮成本。以阿里云服務器帶寬包年包月計費標準[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服務、微服務架構、批數據處理任務等負載建模，這些負載建?？梢宰鳛槲磥淼难芯績热?。后續，將會對本文方法中的參數挖掘過程進一步簡化并完善，并計劃將本文方法應用到其他多種計算資源的研究中。