李漢雄，白光偉，＋，沈 航，承 驍

（1.南京工業(yè)大學 計算機科學與技術系，江蘇 南京211816；2.南京理工大學 高維信息智能感知與系統(tǒng)教育部重點實驗室，江蘇 南京210094）

0 引 言

將現(xiàn)有的本地服務遷移至云中，或者重新開發(fā)一個完全基于云的流媒體服務都會遇到一系列在傳統(tǒng)物理集群環(huán)境中從沒遇過的技術性挑戰(zhàn)［1］。在眾多有關云計算的研究熱點中，作為云計算支撐技術的虛擬化技術正在受到越來越多人的關注。

本文通過對部署在虛擬化環(huán)境中的流媒體系統(tǒng)的一系列的性能分析，通過實驗模擬流媒體系統(tǒng)中一些基本操作以及播放視頻的過程，研究在虛擬化環(huán)境中的用戶體驗和視頻質量。實驗結果表明，在遷移到云中后，沒有經(jīng)過任何優(yōu)化的流媒體業(yè)務受資源隔離和共存虛擬機的影響較大。

1 相關工作

本節(jié)分析綜述虛擬化技術領域的相關工作。隨著近些年云計算的慢慢被人們熟悉，作為其中最重要的技術支撐虛擬化也有不少研究成果。

惠普實驗室Padala Pradeep 等在不同配置的Xen 和OpenVZ環(huán)境下，通過實驗分析了虛擬化對服務器整合的性能的影響［2］。2010年，Wang Guohui等深入研究了Amazon EC2數(shù)據(jù)中心的網(wǎng)絡性能［3］。作者測量了在Amazon EC2虛擬機中處理器共享率、數(shù)據(jù)包時延、TCP/UDP 吞吐量、數(shù)據(jù)包丟失率。通過這些數(shù)據(jù)，作者發(fā)現(xiàn)即使數(shù)據(jù)中心利用率不高，虛擬化還是會顯著的干擾到網(wǎng)絡的吞吐量，使得吞吐量變得極不穩(wěn)定，同時也會使得數(shù)據(jù)包的時延偏差變得不正常。文獻 ［4］則關注了高性能科學計算類型的應用在Amazon EC2中性能表現(xiàn)。文獻 ［5］的作者通過物理機上的客戶端向運行在虛擬化環(huán)境下的HTTP服務器發(fā)送請求，對Xen虛擬化環(huán)境下的不同的網(wǎng)絡應用共存時的網(wǎng)絡吞吐性能做了一定的研究。而在虛擬化與具體應用方面，近年來的研究也不少。文獻 ［6］中，Ishii，Masakuni等通過一個Hadoop模型來測試集群中VM 的特性和位置對于系統(tǒng)性能的影響程度。文獻 ［7］則在他們對網(wǎng)絡游戲的虛擬化技術研究中提出了一種新的混合資源調配模型，該模型使用更小更便宜的專有數(shù)據(jù)中心，同時在繁忙時間會服役虛擬化的云計算資源。文獻 ［8］則通過一系列的實驗表明現(xiàn)有的虛擬化環(huán)境中資源隔離機制對于私有的數(shù)據(jù)中心的影響。文獻 ［9］揭示了基于Xen的虛擬化平臺對諸如在線游戲與多媒體等時延敏感的應用的影響。但是文章對于流媒體與虛擬化的結合的研究并不充分，考慮的是特定場景，不具有普遍性。

針對上述問題，本文以虛擬化環(huán)境中的流媒體服務為對象，從用戶的角度出發(fā)，分析在引入虛擬化環(huán)境后，播放視頻前和播放視頻時的用戶體驗會受到多大的影響。我們的實驗全部是在自己搭建的私有云中完成，相對于使用Amazon EC2作為實驗環(huán)境的研究和使用CloudSim 等模擬軟件的研究來說，所有的實驗環(huán)境都是可見的，而實驗中的所有參數(shù)也是可以由我們自己決定的，因此我們的研究成果更有參考價值。

2 Xen虛擬機監(jiān)視器

本文選擇Xen來搭建我們的虛擬化平臺。Xen是劍橋大學設計開發(fā)的一個開源的虛擬機監(jiān)視器［10］，它允許在一臺機器 （或主機）上運行并行操作系統(tǒng)的多個實例，或甚至不同的操作系統(tǒng)。它在多種不同的商業(yè)和開源應用程序中作為基礎應用被廣泛使用，如服務器虛擬化，基礎設施即服務 （IaaS），桌面虛擬化，安全應用，嵌入式和硬件設備。Xen的架構如圖1所示。

（1）Xen Hypervisor：整個Xen管理程序格外精簡 （少于150 000行），它直接運行在硬件之上，負責管理CPU，內存和I/O 中斷。

（2）Guest Domains：是虛擬環(huán)境，每一個都運行著自己的操作系統(tǒng)和應用程序。Guest VMs與硬件是完全分離的，也就是說它們沒有權限來訪問硬件或者調用I/O 功能。所以它們也通常被稱為DomU。

（3）控制域 （Dom0）：是一個特殊的虛擬機，它有著特別的權限來直接訪問硬件，處理所有對該系統(tǒng)I/O 的請求，并與其它虛擬機進行交互。

（4）Toolstack：Dom0 都包 含control stack （也稱 為Toolstack），通過它用戶可以直接創(chuàng)建、銷毀和配置虛擬機。Toolstack的本質其實是暴露一個接口，這個接口既可以被命令行終端，也可以被圖形化軟件，甚至可以被云業(yè)務管理平臺 （類似OpenStack或者CloudStack）來訪問。

圖1 Xen架構

本文選擇Xen來搭建我們的虛擬化平臺的原因，除了本身架構帶來的優(yōu)勢外，Xen還支持全虛擬化技術。通過全虛擬化技術，我們可以在Xen虛擬機中運行任何未經(jīng)修改的操作系統(tǒng)。通過這一特性，Xen中的虛擬機都可以獲得可觀的性能提升。

3 性能實驗設計及環(huán)境

3.1 實驗設計

用戶在使用一個流媒體系統(tǒng)時，最開始的操作不外乎登錄和注冊、搜索感興趣的視頻、獲取直播節(jié)目單等，系統(tǒng)的響應速度會嚴重影響用戶體驗。為了提升用戶體驗，同時減輕后端服務器的壓力，可以利用現(xiàn)有的技術將這些實時操作背后的動態(tài)請求變?yōu)樽x取靜態(tài)文件，諸如json和xml等。而json和xml本質上只是一種特殊的文本，它們文件體積都很小，因此與服務器通信交互的過程實際可以簡單看成用戶在請求服務器上的小文件。

在用戶完成諸如登陸，搜索等操作后，就要開始觀看他們所需的視頻。對于用戶來說，同一時刻他們只能觀看一個視頻，對于服務器來說，服務模式可以分為兩種場景：微觀上，一個視頻在某個時刻是被很多用戶同時觀看的，例如觀看熱門視頻或者直播；宏觀上，所有的用戶又分散著觀看不同的視頻。

在虛擬化的云環(huán)境中，一臺物理機上不可能只運行一臺虛擬機［11］，由共存虛擬機帶來的資源隔離對于服務質量的影響一直是學術界和商業(yè)公司最為關注的研究熱點。因此我們以用戶開始播放為界，設計了兩組實驗，測試共存虛擬機對于云環(huán)境中流媒體服務的質量的影響。

在第一組實驗中，我們并發(fā)請求虛擬化環(huán)境中Web服務器上的一個HTML頁面，來模擬用戶播放前的操作，同時增加空閑的共存虛擬機數(shù)量，測試共存虛擬機對小文件的并發(fā)訪問性能會造成多大的影響。

在第二組實驗中我們根據(jù)流媒體服務器的服務模式細分成兩個實驗：①第一個實驗我們用腳本生成并發(fā)請求來播放服務器上的同一個視頻來模擬第一個場景。②第二個實驗我們用腳本生成不同視頻點播請求來模擬第二個場景。

在第二組實驗中將流媒體服務與不同類型業(yè)務組合，不同的業(yè)務對應著不同的磁盤負載類型，有的重讀取，有的重寫入。通過這些組合，本文試圖找出對流媒體服務性能影響最大的業(yè)務類型。實驗結果對于云環(huán)境中流媒體系統(tǒng)不同類型的業(yè)務組合的效率優(yōu)化有著非常積極的指導意義。

3.2 硬件環(huán)境

全部的實驗都是在兩臺Dell OptiPlex 3020上完成，一臺模擬服務器，另一臺模擬客戶端產(chǎn)生服務請求。兩臺機器的配置完全一致，由于要部署Xen，因此我們選擇了Ubuntu 12.04LTS作為操作系統(tǒng)。

由于要進行虛擬化操作，我們將機器BIOS 中的Intel虛擬化加速選項激活，使實驗環(huán)境更接近真實的商業(yè)應用環(huán)境。每個虛擬機實例都采用相同的配置，1VCPU，1024MB的內存，20GB的磁盤空間。每個虛擬機實例也都安裝了Ubuntu 12.04操作系統(tǒng)?？蛻魴C的配置情況與服務器基本一致。而在網(wǎng)絡環(huán)境方面，為了排除其它干擾，我們將這兩臺實驗機器連接在一臺獨立的100Mbps 交換機上。

3.3 軟件環(huán)境

實驗一中，我們在服務器上部署了Nginx （版本號為1.4.7）作為Web服務器響應客戶端發(fā)來的并發(fā)訪問請求，在客戶端上我們使用了并發(fā)測試工具ab來產(chǎn)生并發(fā)請求，同時生成測試結果報告。

實驗二 中，我 們 使 用DSS （Darwin streaming server）作為流媒體服務器，在客戶端上所有的視頻請求都是通過openRTSP發(fā)出。我們修改了openRTSP的源碼，使得原本自帶的QoS輸出報告結果更為詳細。同時，我們還自己編寫了openRTSP的并發(fā)腳本，使得實驗步驟簡單化。

另外，我們使用Filebench在共存虛擬機上產(chǎn)生各種類型的磁盤負載實驗中，我們使用了3種Filebench自帶的負載模式：

（1）文件服務器：模擬的簡單的文件服務器上的I/O操作。執(zhí)行了一系列操作，包括創(chuàng)建、刪除、附加、讀取、寫入和對文件目錄樹上的屬性修改。默認有50個線程。

（2）數(shù)據(jù)庫服務器：模擬數(shù)據(jù)庫的操作。以Oracle 9i I/O 為模型對系統(tǒng)進行文件操作，主要是測試隨機讀取和寫入性能。默認有200個讀取進程、10個同步寫進程以及1個日志進程。

（3）Web服務器：模擬簡單的Web服務器上的I/O 操作。對一個目錄樹下的多個文件會進行打開－讀?。P閉，這一整套操作，同時也會記錄日志。默認有100個線程。

3.4 性能指標

在進行具體實驗之前，我們再來介紹下實驗結果中我們主要關注的幾個性能指標：

（1）丟包率：丟包對于流媒體服務來說會造成很直觀的影響，要么畫面質量下降，甚至出現(xiàn) “花屏”，要么丟幀，造成畫面不連續(xù)。

（2）包間隔：根據(jù)RTP標準，包間隔指的是流文件里連續(xù)兩個數(shù)據(jù)包的到達時間差。如果包間隔太大會造成視頻播放的中斷，影響用戶體驗。

（3）抖動：根據(jù)RTP標準文檔，抖動指的是數(shù)據(jù)包接收者相對發(fā)送者的時間間隔差值的平均偏差。它一流文件的時間戳為單位。

盡管openRTSP自帶的QoS報告已經(jīng)比較詳細，但我們還是通過修改源代碼，增加了抖動的數(shù)據(jù)，同時為了方便評估和分析實驗數(shù)據(jù)，我們還增加了代碼使得QoS報告能夠輸出為文件。

4 實驗結果及性能分析

4.1 實驗一：空閑虛擬機對流媒體服務器的性能影響

我們首先啟動第一臺虛擬服務器 （Dom－1），Dom－1上部屬了Nginx來響應客戶端的服務請求，在客戶機上則使用性能測試工具ab來產(chǎn)生并發(fā)請求，向服務器發(fā)送1000個并發(fā)請求，這1000個請求同時指向Nginx服務器上一個1kB的頁面，測試并發(fā)的請求完成情況，結果將作為后續(xù)實驗的基準對比數(shù)據(jù)。在得出基準數(shù)據(jù)后，我們改變空閑虛擬機的數(shù)量，進行相同的實驗。實驗結果見表1。

表1 1kB文件的訪問數(shù)據(jù)

由表1可知，在基準測試中，完成全部連接請求總耗時226ms，最短請求處理時間為5ms。最大連接數(shù)為911，即當并發(fā)連接數(shù)超過911后，服務器開始出現(xiàn)瓶頸，服務器完成請求時間從15ms躍升為219ms。

在增加了一臺空閑的虛擬機后，完成全部連接請求總耗時237ms，比基準數(shù)據(jù)長了4.8%。最短請求處理時間為8ms，比基準數(shù)據(jù)慢了60%。服務器在并發(fā)連接數(shù)達到898后就遇到了瓶頸，服務器的并發(fā)能力下降了1.4%。

在空閑虛擬機數(shù)量增加為兩臺后，完成全部連接請求總耗時245ms，比基準數(shù)據(jù)長了8.4%。最短請求處理時間達到了10ms，是基準數(shù)據(jù)的2倍。服務器在并發(fā)連接數(shù)達到859后遇到了瓶頸，并發(fā)能力相對基準數(shù)據(jù)下降了5.7%。

由這3個實驗的結果可以得出，在只有兩臺空閑虛擬機的情況下，服務器的性能已經(jīng)有了較為嚴重的下降，而在實際的商業(yè)環(huán)境中，一臺物理機上運行的虛擬機數(shù)量可能有40甚至60臺，可以預見，當空閑虛擬機的數(shù)量不斷增加時，實驗中的Web服務器的并發(fā)性能還會有著更為明顯的下降。而并發(fā)性能的下降意味著如果有大量用戶進行播放前操作 （登錄、注冊、搜索等）時，他們的服務質量會受到損害。而在用戶的慣性思維中，流媒體系統(tǒng)中最容易發(fā)生延時和卡頓的階段是在觀看視頻時。如果登錄、搜索、更新等這些操作都有較長的時延，那么用戶對于這個系統(tǒng)的認可度就會急劇降低，甚至放棄繼續(xù)使用。

為了對比小文件和大文件的訪問性能，我們增加了兩組訪問10kB 和20kB 文件的實驗，由實驗數(shù)據(jù)表2、表3可以得出，無論增加了幾臺空閑虛擬機，文件的并發(fā)訪問數(shù)據(jù)并沒有什么明顯的改變。因此，我們認為在虛擬化環(huán)境中，小文件的并發(fā)性能更容易受到空閑虛擬機的影響，而較大的文件則沒有什么影響。

在前面的實驗中，為了模擬真實環(huán)境，我們讓增加的空閑虛擬機分配在與Dom－1同一個物理核心上，在接下來的試驗中，我們通過命令將虛擬機分配到不同的物理核心上，然后重復之前實驗步驟，再次比較并發(fā)訪問文件的性能。表4是分配不同物理核心后的實驗數(shù)據(jù)。

將虛擬機分配不同的CPU 核心后，由表4 可以發(fā)現(xiàn)，即使增加了共存虛擬機的數(shù)量，流媒體服務器上小文件的并發(fā)訪問性能也沒有明顯的下降，甚至可以認為完全沒有影響。

本節(jié)的實驗中我們探究了空閑虛擬機對流媒體系統(tǒng)的影響，從實驗結果可以得出當一顆物理核心上運行多個共存虛擬機時，即使這些共存的虛擬機上沒有任何負載，對于流媒體系統(tǒng)也會產(chǎn)生影響，當這些虛擬機運行在不同的CPU 物理核心上時，流媒體服務器就幾乎沒有任何的性能下降。而在虛擬化的云環(huán)境中，CPU 和內存這兩種資源是通過分割從而分配給多個虛擬機，共存虛擬機對于流媒體服務器的影響，本質上來說就是由于CPU 共享造成的。在有多個虛擬機后，CPU 的調度隊列里不再只有流媒體服務器的CPU 請求，還包含了其它共存虛擬機的一些請求，因此在小文件并發(fā)訪問這一依賴CPU 的性能測試中，我們觀測到了較為明顯的性能下降。所以為了提高云環(huán)境中流媒體服務的性能，我們應當盡可能將文件靜態(tài)化，緩存化，從流媒體服務器上分離出來，從而減輕流媒體服務器的壓力，提高響應速度，提升用戶體驗。

表2 10kB文件的訪問數(shù)據(jù)

表3 20kB文件的訪問數(shù)據(jù)

表4 分配不同物理核心后的小文件訪問數(shù)據(jù)

4.2 實驗二：磁盤負載對流媒體服務的性能影響

4.2.1 場景一：單一視頻并發(fā)訪問

在場景一中，所有并發(fā)請求都指向同一個視頻文件。我們選取的測試視頻長度為60s，大小為32.9MB，視頻與音頻的一些參數(shù)見表5。

表5 視頻文件基本參數(shù)

通過修改并發(fā)腳本中的并發(fā)數(shù)，我們觀察到，針對選定視頻，當同時觀看同一個視頻的用戶數(shù)為12時，這12個用戶享受的視頻服務質量沒有任何的損失。實驗數(shù)據(jù)見表6，這一組數(shù)據(jù)也會作為后續(xù)操作的基準數(shù)據(jù)進行參考比較。

表6 基準數(shù)據(jù)

由于實驗環(huán)境為內網(wǎng)，所以整個流媒體文件的抖動非常小，包間隔的平均值也比較小，視頻流的平均包間隔約為2.37ms，最大間隔也就在101ms左右。而由于音頻流的文件體積相對視頻流來說要小很多，所以包間隔要比視頻流來的大。

在得到基準數(shù)據(jù)后，我們使用Filebench在共存的虛擬機加上不同類型的負載，再進行相同的實驗。我們用一臺虛擬機作為流媒體服務器，另一臺虛擬機作為 “干擾”服務器，將這兩臺虛擬機分配到了不同的物理核心上，這樣可以避免實驗結果受CPU 干擾，從而讓干擾因素只剩下磁盤。實驗結果如表7、表8和圖2所示。數(shù)據(jù)中的Base表示基準數(shù)據(jù)組，而File、Oltp和Web分別對應我們在Filebench中選擇的負載模式。從實驗數(shù)據(jù)中可以看出，在用戶都訪問單一視頻時，與流媒體共存的虛擬機加上負載后，在3組負載中，Oltp模式也就是數(shù)據(jù)庫服務器對流媒體服務器的影響最大，視頻包間隔比基準數(shù)據(jù)大了48.7%，音頻包間隔比基準數(shù)據(jù)大了10%，根據(jù)計算，視頻抖動比基準數(shù)據(jù)大了8.3%，音頻抖動比基準數(shù)據(jù)大了12.2%。而File和Web模式則對流媒體系統(tǒng)的影響較小，沒有Oltp明顯。因此為了提高整體系統(tǒng)的性能，在部署流媒體云服務時應該考慮將盡可能多的數(shù)據(jù)做成緩存，而不是直接訪問后臺數(shù)據(jù)庫，這樣能提高用戶的訪問和響應速度，減少數(shù)據(jù)庫服務器對流媒體服務器的干擾。

表7 場景一下視頻的包間隔/ms

表8 場景一下音頻的包間隔/ms

圖2 場景一下音視頻流的抖動

4.2.2 場景二：多個視頻同時訪問

在場景二中，為了模擬流媒體系統(tǒng)中另一個常見的流量模型，即沒有某個視頻被大量用戶同時訪問，我們修改了測試腳本，請求不同的視頻。經(jīng)過不斷增加用戶數(shù)量，最終得到當為21個用戶時，整個系統(tǒng)的服務質量沒有任何損耗，客戶端上也觀察不到丟包。通過統(tǒng)計，這21個視頻總大小為611.4MB，長度都為60s。而由于這些視頻都是動態(tài)碼率，因此不會像第一組實驗遇到高碼率的畫面疊加造成的網(wǎng)絡帶寬高峰，所以支持的并發(fā)數(shù)量比實驗一要大。

在場景二中繼續(xù)重復場景一中的步驟，通過Filebench來給與流媒體服務器共存的虛擬機上添加不同的磁盤負載模式，比較在場景二中，用戶接收到的視頻服務質量會有什么樣的影響。

實驗數(shù)據(jù)，如圖3，圖4 和表9 所示，數(shù)據(jù)中的Base組表示基準數(shù)據(jù)即沒有任何負載。由數(shù)據(jù)可以看出，對流媒體服務器來說，F(xiàn)ile模式對流媒體服務器的性能造成了非常嚴重的影響，平均包間隔指標中，最嚴重的接近3倍，而在最大包間隔指標中，F(xiàn)ile的數(shù)據(jù)甚至比基準數(shù)據(jù)差了70多倍。包間隔變大意味著客戶端收到連續(xù)兩個數(shù)據(jù)包時間變長，視頻卡頓甚至丟包的可能性也就變大，最終都會影響客戶端的視頻質量和用戶體驗。

而Oltp和Web模式對平均包間隔影響很小，但對最大包間隔指標有比較明顯的影響，對于整個視頻來說，可以認為大部分的視頻包都能穩(wěn)定得連續(xù)達到，但會存在一小部分數(shù)據(jù)包間隔較長的時間才能達到，結果就是用戶觀看的視頻產(chǎn)生畫面卡頓、清晰度下降，音質變差。

圖3 視頻流的平均包間隔

圖4 音頻流的平均包間隔

表9 視頻流與音頻流的最大包間隔/ms

在抖動指標中，如圖5、圖6所示，影響最大的依然是File模式，相對較小的是Web模式。在絕大部分的視頻測試結果中，加上負載后抖動都成倍的增加了，這僅僅是在內網(wǎng)沒有其它網(wǎng)絡干擾的情況下的數(shù)據(jù)。如果一個商業(yè)的流媒體云服務上線開始服務后，可想而知在實際網(wǎng)絡環(huán)境中的抖動會加劇到什么程度。而比較Oltp與Web模式對抖動影響可以看出，Oltp對流媒體服務器的影響更大，再次驗證了我們在實驗一的建議，通過緩存可以提高流媒體云服務的整體性能。

圖5 視頻流的抖動

圖6 音頻流的抖動

在分析完了包間隔和抖動后，我們來看一下另一個性能指標，丟包率，這里我們通過接收到包數(shù)量來表示，實驗數(shù)據(jù)如圖7、圖8所示。通過實驗結果可以得出，無論是視頻流還是音頻流，F(xiàn)ile模式對于流媒體服務的影響最大，丟包非常嚴重，最嚴重的一組接收到的數(shù)據(jù)包連一半都不到，肯定無法滿足觀看視頻的基本要求。而對于Oltp 與Web來說，丟包率非常小，結合包間隔和抖動后，這兩個模式雖然幾乎收到全部的數(shù)據(jù)包，但是它們到達的時間差比較大，可以認為用戶在客戶端上可以接收到全部的視頻和音頻文件，但是會出現(xiàn)卡頓的情況，視頻質量和用戶體驗還是有著不小的損失。

圖7 視頻流接收到包數(shù)量

圖8 音頻流接收到包數(shù)量

在完成實驗二中的所有實驗后，我們發(fā)現(xiàn)當流媒體服務器與其它服務器共存時，這些共存服務器上如果存在著重磁盤操作的應用時，流媒體服務器的性能肯定會受到影響。場景二中的視頻質量和用戶體驗受到的性能損失相比較場景一更加明顯。這是因為，流媒體服務器中包含了大量網(wǎng)絡傳輸操作，因而Dom0會產(chǎn)生中斷來發(fā)送流媒體服務器中的數(shù)據(jù)包，而當共存的虛擬機進行磁盤操作時，由于磁盤在虛擬機之間是共享的，不是分割的，所有的虛擬機中的磁盤中斷都由Dom0來管理，而磁盤中斷的優(yōu)先級比網(wǎng)絡中斷的優(yōu)先級要高，并且它們的數(shù)量要遠多于流媒體服務器中的網(wǎng)絡中斷數(shù)量，因此Dom0 會優(yōu)先響應那些磁盤中斷，從而使得流媒體服務器得不到充分的響應。

5 結束語

本文針對一個部署在云環(huán)境下的流媒體系統(tǒng)進行了性能分析。首先通過訪問小文件來模擬用戶與服務器通信時傳輸json和xml文件的情形，分析了空閑的共存虛擬機對于流媒體服務器向用戶提供播放前服務時性能的影響。通過實驗發(fā)現(xiàn)即使沒有任何負載，共存的虛擬機在沒有進行CPU 隔離的情況下依然會對流媒體服務器產(chǎn)生一定的性能影響。

通過編寫并發(fā)腳本，同時搭配不同的磁盤負載模式，來模擬流媒體服務器在響應用戶觀看過程中最常見的兩種場景，分析流媒體服務器與這些應用共存時性能降低程度。實驗結果表明，在場景一中，用戶同時觀看同一個視頻時，共存虛擬機上的磁盤負載對于流媒體服務器影響比較小。但在比較3個負載模型的結果后，還是可以發(fā)現(xiàn)較為明顯的是數(shù)據(jù)庫服務器，因此減少對于后端數(shù)據(jù)庫的訪問可以提高流媒體服務器的性能。在場景二中，用戶分散觀看不同視頻時，共存虛擬機對于流媒體服務器的影響就要大的多，其中File模式的影響最大，這是由于File模式對于磁盤操作最為頻繁，造成大量的I/O 中斷，這些中斷的優(yōu)先級是高于流媒體服務器中的網(wǎng)絡傳輸中斷，因此流媒體服務器在場景二中受到的影響更大，甚至不能正常工作。

我們的工作可以作為研究云計算環(huán)境與流媒體服務器性能的一個重要基礎，為考慮將流媒體服務與云融合的研究者提供性能優(yōu)化方面的參考。

［1］Cheng Luwei，Wang Cho－Li.Network performance isolation for latency－sensitive cloud applications［J］.Future Generation Computer Systems，2013，29 （4）：1073－1084.

［2］Padala Pradeep.Performance evaluation of virtualization technologies for server consolidation［R］.HP Labs Tec Report，2007.

［3］Wang Guohui，TS Eugene Ng.The impact of virtualization on network performance of Amazon EC2data centerm ［C］//Proceedings of IEEE INFOCOM，2010：1－9.

［4］Walker E.Benchmarking Amazon EC2for high－performance scientific computing［J］.Usenix Login，2008，33 （5）：18－23.

［5］Mei Y，Liu L，Pu X，et al.Performance measurements and analysis of network i/o applications in virtualized cloud ［C］//Proceedings of IEEE International Conference on Cloud Computing，2010：59－66.

［6］Ishii Masakuni，Han Jungkyu，Makino Hiroyuki.Design and performance evaluation for hadoop clusters on virtualized environment［C］//Proceedings of IEEE International Conference on Information Networking，2013：244－249.

［7］Nae Vlad.The impact of virtualization on the performance of massively multiplayer online games ［C］//Proceedings of the 8th Annual Workshop on Network and Systems Support for Games，2009：9－14.

［8］Somani G，Chaudhary S.Application performance isolation in virtualization ［C］//Proceedings of the IEEE International Conference on Cloud Computing，2009：41－48.

［9］Barker Sean Kenneth，Prashant Shenoy.Empirical evaluation of latency－sensitive application performance in the cloud ［C］//Proceedings of the First Annual ACM SIGMM Conference on Multimedia Systems.ACM，2010：35－46.

［10］Chisnall D.The definitive guide to the xen hypervisor［M］.Pearson Education，2008：16.

［11］Ben P，Justin P，Teemu K，et al.Extending networking into the virtualization layer［C］//Proceedings of the 8th ACM Workshop on Hot Topics in Networks（HotNets－VIII），2009.