黃浩程，何彥，顏金堯

(1.中國傳媒大學(xué) 計算機與網(wǎng)絡(luò)中心，北京100024；2.中國傳媒大學(xué) 理工學(xué)部，北京100024)

?

流媒體服務(wù)器的性能測試和瓶頸分析

黃浩程1，何彥2，顏金堯2

(1.中國傳媒大學(xué) 計算機與網(wǎng)絡(luò)中心，北京100024；2.中國傳媒大學(xué) 理工學(xué)部，北京100024)

摘要：討論了流媒體系統(tǒng)的各種性能指標(biāo)和流媒體服務(wù)器的平臺性能限制之間的關(guān)系。我們通過改變下列條件：連接數(shù)，并發(fā)活動的媒體文件的數(shù)量，以及流媒體的編碼格式和碼流，來測量流媒體服務(wù)器的CPU空閑時間，IO等待，內(nèi)存，網(wǎng)絡(luò)帶寬的變化，找出流媒體服務(wù)器的性能指標(biāo)和制約瓶頸。通過有針對性的提高服務(wù)器處理瓶頸的能力，可以進一步提高流媒體服務(wù)的性能。

關(guān)鍵詞：媒體；性能測量；瓶頸分析

1背景介紹

典型流媒體服務(wù)包括VOD點播，視頻會議，遠程教育，數(shù)字圖書館等等。過去，流媒體系統(tǒng)的服務(wù)質(zhì)量取決于網(wǎng)絡(luò)帶寬，網(wǎng)絡(luò)延遲，媒體編碼壓縮效率和解碼客戶端的性能等等。網(wǎng)絡(luò)的傳輸能力是制約流媒體發(fā)展的關(guān)鍵因素之一。隨著高速網(wǎng)絡(luò)的發(fā)展和編碼技術(shù)成熟，流媒體服務(wù)器的硬件性能越來越成為制約流媒體系統(tǒng)的服務(wù)質(zhì)量的關(guān)鍵因素。

隨著帶寬的增加，流媒體服務(wù)器的硬件性能已經(jīng)逐步成為制約流媒體服務(wù)質(zhì)量的一個重要因素。找出媒體服務(wù)器的瓶頸不但是優(yōu)化流媒體系統(tǒng)的前提條件，而且也為分析評估流媒體服務(wù)器的性能提供理論基礎(chǔ)。當(dāng)前，關(guān)于如何找出媒體服務(wù)器的瓶頸，評估性能的研究仍比較少[1，2，3]。因此，我們通過評估流媒體服務(wù)器的性能，試圖整理一套通過實驗評價分析流媒體服務(wù)器的瓶頸的方法。

下文的組織結(jié)構(gòu)如下：第二部分，介紹流媒體服務(wù)的模型與性能指標(biāo)。第三部分，介紹我們的實驗環(huán)境和實驗方法。第四部分，分析實驗結(jié)果。第五部分，總結(jié)。

2流媒體服務(wù)的模型與性能指標(biāo)

流媒體服務(wù)器是向用戶提供流媒體服務(wù)的基本功能單元，性能的好壞會直接影響到流媒體系統(tǒng)服務(wù)能力。在流媒體服務(wù)器的性能中，流媒體的吞吐量及并發(fā)處理能力是其中最重要指標(biāo)。下面我們簡要介紹一下的流媒體服務(wù)器提供服務(wù)的過程：

(1)當(dāng)客戶端的一個請求到達時，媒體服務(wù)器從硬盤存儲中讀取相應(yīng)媒體內(nèi)容，并把其放入到內(nèi)存中；

(2)在把媒體內(nèi)從發(fā)送到網(wǎng)絡(luò)前，媒體內(nèi)容需要由CPU按照協(xié)議標(biāo)準(zhǔn)進行分段，編碼、封裝等操作；

(3)把整理好的流媒體數(shù)據(jù)發(fā)送到網(wǎng)卡；

(4)由網(wǎng)卡把內(nèi)容發(fā)送到網(wǎng)絡(luò)，給客戶端提供服務(wù)。

通過上述過程，我們能發(fā)現(xiàn)影響流媒體服務(wù)器性能的四個關(guān)鍵因素：CPU，內(nèi)存，磁盤讀取能力和網(wǎng)絡(luò)吞吐能力。

因此，我們通過觀察服務(wù)器的CPU的利用率及I/O等待，內(nèi)存占用大小，磁盤讀寫速度以及服務(wù)器的網(wǎng)絡(luò)流量來獲取瓶頸所在。

3實驗環(huán)境和實驗方法

3.1　實驗環(huán)境

如表1、表2所示。我們采用操作系統(tǒng)是Linux Enterprise 5。采用Live555提供基于RTSP的流媒體服務(wù)，采用Lighttpd提供基于Http的流媒體服務(wù)。通過systat來采集服務(wù)器的各種性能數(shù)據(jù)：CPU、磁盤、內(nèi)存等。此外，我們通過oprofile來分析服務(wù)器產(chǎn)生瓶頸的原因。

表1　軟件環(huán)境

表2　硬件環(huán)境

3.2　實驗方法

第一步，在服務(wù)器上，我們在運行流媒體服務(wù)軟件的同時，運行我們的一個腳本程序，調(diào)用systat來收集性能數(shù)據(jù)。第二步，我們在客戶端通過運行openRtsp模擬向服務(wù)器發(fā)出不同并發(fā)數(shù)，帶寬流量、訪問媒體文件數(shù)等等，同時使用vlc實際播放流媒體，觀察流媒體播放質(zhì)量。最后我們就能從服務(wù)器收集不同條件下的服務(wù)器性能數(shù)據(jù)。為了分析簡便直觀，我們把收集到數(shù)據(jù)導(dǎo)入到excel中并做成圖表進行分析。

3.3　采集頻率的選定原則

我們采用的數(shù)據(jù)采集工具systat的最少采集間隔是1秒，我們基于以下原則確定我們的采樣頻率：

* 采樣間隔應(yīng)盡可能的小，以便獲得更準(zhǔn)確的數(shù)據(jù)，有利于我們進行瓶頸分析；

* 采樣的業(yè)務(wù)占用服務(wù)器性能應(yīng)盡可能小，以免影響實驗結(jié)果。

為了找到合適的采樣頻率，我們在不運行媒體服務(wù)的環(huán)境下，運行的采樣工具，通過觀察該服務(wù)器的性能變化來選擇最合適的采樣間隔。觀察發(fā)現(xiàn)采樣頻率在1秒和5秒的情況下消耗相近的CPU資源，而1秒次是最小的采樣間隔。因此，我們選擇1秒的采樣間隔。

4實驗與性能分析

在本部分中，我們通過分析兩個有代表意義的實驗來找出流媒體服務(wù)器的性能瓶頸所在。在下面的圖標(biāo)中，CPU Idle表示的是CPU空閑的百分比。iowait表示CPU在等待磁盤的IO操作完成(此時CPU處于等待狀態(tài))所占用的百分比。

4.1　實驗一

實驗環(huán)境如下：并發(fā)連接數(shù)為30，所有媒體的格式都為mpeg，碼流為5MB/s，我們通過逐步增加訪問的媒體數(shù)來做不同的實驗：分別通過把30個請求訪問同1個媒體文件，分別訪問10個媒體文件，分別訪問30個媒體文件來對比分析，其中1個媒體文件和30個媒體文件的實驗結(jié)果分別如圖1和圖2所示：

圖1　訪問同一個媒體文件(上圖為CPU idle百分比，下圖為CPU iowait百分比)　

圖2　同時訪問30個不同的文件(上圖為CPU idle百分比，下圖為CPU iowait百分比)　

通過觀察圖1和圖2，我們可以發(fā)現(xiàn)：當(dāng)客戶端沒有發(fā)起連接請求的時候，服務(wù)器上的CPU idle和iowait分別為接近于100%和0%。當(dāng)客戶端的請求到達后，iowait迅速提高，同時idle開始下降。當(dāng)iowait開始下降時，idle出現(xiàn)了緩慢的上升。當(dāng)客戶端訪問結(jié)束后，CPU idle和iowait的數(shù)值有恢復(fù)到初始狀態(tài)。

另外，我們通過觀察圖1與圖2，我們還可以發(fā)現(xiàn)，在流媒體服務(wù)的不同階段，CPU的利用率是不一樣的：在連接的初始階段，CPU除了需要處理文件的讀取、分段和按協(xié)議封裝的業(yè)務(wù)外，還需要處理網(wǎng)絡(luò)連接的建立，使得在流媒體服務(wù)在初始階段比流媒體的傳輸階段要消耗更多的CPU資源。

通過對比各次實驗結(jié)果，我們可以發(fā)現(xiàn)，隨著訪問文件數(shù)的增加，CPU iowait也隨著增加。當(dāng)訪問的文件數(shù)達到30個時，iowait到達了80%，占用了大部分的CPU資源。此時，由于大部分的CPU時間片都處于等待 磁盤IO操作，CPU的處理能力并沒有達到最大限度的利用。因此，CPU并沒有成為系統(tǒng)的瓶頸，系統(tǒng)的瓶頸出現(xiàn)在磁盤的IO操作上。

由于篇幅的關(guān)系，我們沒有給出內(nèi)存的使用率圖表，但從實驗的結(jié)果看來，隨著訪問文件數(shù)的增多，剩余內(nèi)存也逐步下降。最終，剩余內(nèi)存穩(wěn)定在50，000KB左右。由于內(nèi)存并沒有耗盡，所以內(nèi)存也不是系統(tǒng)的瓶頸。由此，我們認為此時磁盤的讀寫能力是系統(tǒng)中最主要的瓶頸。

為了確認磁盤的讀寫能力是否為最主要瓶頸，我們做了以下的實驗：為了能夠使用更多地內(nèi)存，我們把測試平臺放在了64位的操作系統(tǒng)上。我們這次實驗的目的是對比在ext3和tmpfs兩種文件格式上的服務(wù)器性能的不同表現(xiàn)。其中ext3是建立在sata磁盤上，tmpfs則直接使用內(nèi)存或者swap分區(qū)。為了確保tmpfs完全使用內(nèi)存，我們使用“swapoff -a”命令來關(guān)閉swap分區(qū)。在媒體實驗前，我們通過使用命令“dd”來進行文件的讀寫操作，可以發(fā)現(xiàn)tmpfs的讀寫能力比ext3提高了近10倍。隨后我們重做了同時訪問30個不同流媒體文件的實驗，實驗結(jié)果如圖3和圖4所示：

圖3　在ext3上同時訪問30個不同的文件(上圖為CPU idle百分比，下圖為CPU iowait百分比)　

圖4　在tmpfs上同時訪問30個不同的文件(上圖為CPU idle百分比，下圖為CPU iowait百分比)　

從圖3中，我們可以看到，32位域64位操作系統(tǒng)在sata磁盤上的流媒體服務(wù)性能基本一致：當(dāng)訪問的媒體數(shù)達到30個的時候，CPU iowait達到了80%，而idle則為0%。我們認為服務(wù)的主要瓶頸為磁盤的讀寫能力。

圖4表示的是采用了tmpfs時的服務(wù)器性能。由于使用了內(nèi)存，讀寫能力得到大幅度的提升，CPU iowait大部分時候都為0%，只在85秒時出現(xiàn)了一個小得高峰。服務(wù)器的整體服務(wù)性能得到了顯著的提升。由此，我們可以確定在此環(huán)境中，磁盤的讀寫性能是流媒體服務(wù)的主要瓶頸。

4.2　實驗二

在第二個實驗中，我們的實驗條件如下：媒體文件的格式為MPEG2，碼流為5MB/s，每個客戶端連接訪問相同的媒體文件，我們通過從1到30改變同時連接數(shù)來觀察在不同并發(fā)連接數(shù)下，流媒體服務(wù)器的性能表現(xiàn)，結(jié)果如圖5和圖6所示。

圖5　一個連接請求的CPU利用率及iowait百分比　

圖6　30個連接請求的CPU利用率及iowait百分比　

從圖5和圖6的對比分析來看，隨著并發(fā)連接數(shù)的提高，CPU利用率也逐步提高。當(dāng)并發(fā)連接數(shù)提高到30個時，CPU利用率達到了80%以上，而此時的iowait幾乎是0%，可以看出磁盤的讀寫能力并不是瓶頸，CPU的運算能力成為了瓶頸。

為了找出此時CPU的資源主要在處理那些任務(wù)，我們使用了oprofile4工具來收集CPU使用的信息，如圖7所示。

從圖7中可以看到，大部分的CPU運算都消耗在MPEG1or2VideoStreamParser ：：parseSlice()。這個函數(shù)主要是用于對媒體文件進行分析拆包等運算。所以在此環(huán)境下，我們得出結(jié)論：當(dāng)磁盤讀寫能力不是瓶頸時，CPU的運算能力將成為主要的系統(tǒng)瓶頸，而且CPU資源主要用于對媒體文件的分析處理。

為了證明我們的結(jié)論，我們做了以下的實驗：我們分別在服務(wù)器A：CPU為Intel(R)Xeon(TM)CPU 2.80GHz*1(核數(shù))*4(個數(shù))和服務(wù)器B：Intel(R)Xeon(R)CPU X5460 3.16GHz*4(核數(shù))*8(個數(shù))的服務(wù)器上進行實驗，服務(wù)器B的CPU處理能力是服務(wù)器A的8倍多。兩個平臺上都使用tmpfs文件格式消除磁盤的讀寫瓶頸，我們使用并發(fā)50個連接請求進行實驗。實驗結(jié)果見圖8：

圖7　30個并發(fā)連接請求時，opfrofile收集的CPU使用信息 　

圖8　同CPU能力下的流媒體服務(wù)器的性能表現(xiàn)(上圖為服務(wù)器A的CPU利用率，下圖服務(wù)器B的CPU利用率)　

當(dāng)我們把并發(fā)連接數(shù)提高到50個的時候，我們可以看到在服務(wù)器A中，CPU的利用率已達到100%，在客戶端中觀看視頻效果并不流暢，卡頓非常嚴(yán)重，服務(wù)器已達到瓶頸。而從服務(wù)器B的情況看來，當(dāng)CPU的能力提高了8倍后，CPU的利用率大部分時候在20%以下，而且客戶端中觀看視頻的效果明顯改善。說明了我們的推測是正確地。

4.3　其他實驗

除了以上的實驗外，我們還做了其他一些實驗并得到了以下的一些結(jié)論：

i. 并發(fā)連接數(shù)固定為20，我們改變媒體文件的碼流(2MB/s，5MB/s，10MB/s)，實驗結(jié)果表明，隨著碼流的增加，CPU的利用率越來越高，當(dāng)?shù)竭_10MB/s時，CPU的idle為0%，CPU的處理能力成為了瓶頸。

ii. 我們分別對媒體的編碼格式H.264和MPEG2進行測試，可以看到MPEG2需要比H.264占用更多CPU資源：同為20個并發(fā)連接，5MB/s碼率的條件下，H.264的編碼格式，CPU的空閑資源有80%，而MPEG2只有60%。

iii. 我們檢驗了不同流媒體協(xié)議的區(qū)別：HTTP和RTSP5。我們采用lighttpd來作為HTTP流媒體服務(wù)的提供者，RTSP則采用Live555提供。實驗表明，相同情況下，當(dāng)RTSP服務(wù)器中CPU資源耗盡時，HTTP服務(wù)器只占用了10%的CPU資源，HTTP比RTSP的效率更高。從上面的實驗2看來，RTSP協(xié)議除了傳輸媒體文件外，還需要對媒體文件進行分析組裝，而HTTP則主要關(guān)注傳輸，所以HTTP協(xié)議下，流媒體服務(wù)的性能得到更好表現(xiàn)。

5結(jié)論

我們通過分別改變磁盤讀寫能力，CPU處理能力，媒體碼率和帶寬的因素來進行流媒體的連接實驗，逐步分析流媒體服務(wù)器的真實性能瓶頸所在，我們的結(jié)論總結(jié)如下：

1.在大多數(shù)的情況下，磁盤的讀寫能力是流媒體服務(wù)器的主要瓶頸；

2.當(dāng)磁盤能力提升以后，CPU的處理能力將成為流媒體服務(wù)器的主要瓶頸；

3.高效的媒體編碼格式能有效的提高服務(wù)器的服務(wù)能力；

4.相同的服務(wù)器條件下，采用HTTP協(xié)議比RTSP協(xié)議，能帶來更好的系能表現(xiàn)。

參考文獻

[1]徐茂.流媒體服務(wù)器性能調(diào)優(yōu)關(guān)鍵點分析[J].電視技術(shù)，2014，(12).

[2]He Yan，Huang Haocheng，Yan Jinyao.Performance Measurement and Bottleneck Analysis for Streaming Media Servers[C] .icmt-13，November 2013.

[3]Jinyao Yan，Muhlbauer W，Plattner B. Analytical Framework for Improving the Quality of Streaming Over TCP[J].IEEE Transactions on Multimedia，2012，14(6)：1579，1590.

[4]oprofile[DB/OL]. http：//www.ibm.com/developerworks/cn/linux/l-oprof/.

[5]RTSP：[DB/OL]. http：//www.ietf.org/rfc/rfc2326.txt.

[6]H.264[DB/OL]. http：//www.itu.int/rec/T-REC-H.264-201402-I/en.

(責(zé)任編輯：王謙)

Performance Analysis of Stream Media Server

HUANG Hao-cheng1，HE Yan2，YAN Jin-yao2

(1.Computer and Network Center，Communication University of China，Beijing 100024，China；

2.School of Science and Technology，Communication University of China，Beijing 100024，China)

Abstract：We discuss the relationship between the capability of the stream media system and the performance constraints of the stream media server. In out experiments，we try to change the following environment：the number of concurrent connections，the number of media files opened the format of streaming media and network bandwidth. By measuring CPU idle time，IO waiting time，RAM of the streaming media server，we find out the performance and bottlenecks of streaming media system. Through improving the important capability of media server，the performance of streaming media service can be improved significantly.

Keywords：stream media；performance measurement；bottleneck analysis

作者簡介：黃浩程(1979-)，男(漢族)，廣東惠州人，中國傳媒大學(xué)計算機與網(wǎng)絡(luò)中心.E-mail：infosec@cuc.edu.cn

收稿日期：2015-06-02

中圖分類號：TP37

文獻標(biāo)識碼：A

文章編號：1673-4793(2015)05-0022-07