云計算環境下實時流媒體業務的性能研究

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

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

0 引 言

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

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

1 相關工作

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

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

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

2 Xen虛擬機監視器

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

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

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

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

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

圖1 Xen架構

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

3 性能實驗設計及環境

3.1 實驗設計

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

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

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

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

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

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

3.2 硬件環境

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

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

3.3 軟件環境

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

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

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

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

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

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

3.4 性能指標

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

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

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

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

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

4 實驗結果及性能分析

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

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

表1 1kB文件的訪問數據

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

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

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

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

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

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

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

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

表2 10kB文件的訪問數據

表3 20kB文件的訪問數據

表4 分配不同物理核心后的小文件訪問數據

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

4.2.1 場景一：單一視頻并發訪問

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

表5 視頻文件基本參數

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

表6 基準數據

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

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

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

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

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

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

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

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

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

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

圖3 視頻流的平均包間隔

圖4 音頻流的平均包間隔

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

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

圖5 視頻流的抖動

圖6 音頻流的抖動

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

圖7 視頻流接收到包數量

圖8 音頻流接收到包數量

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

5 結束語

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

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

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

［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.