黃浩程，何彥，顏金堯

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

?

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

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

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

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

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

1背景介紹

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

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

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

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

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

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

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

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

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

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

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

3實(shí)驗(yàn)環(huán)境和實(shí)驗(yàn)方法

3.1　實(shí)驗(yàn)環(huán)境

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

表1　軟件環(huán)境

表2　硬件環(huán)境

3.2　實(shí)驗(yàn)方法

第一步，在服務(wù)器上，我們?cè)谶\(yùn)行流媒體服務(wù)軟件的同時(shí)，運(yùn)行我們的一個(gè)腳本程序，調(diào)用systat來(lái)收集性能數(shù)據(jù)。第二步，我們?cè)诳蛻舳送ㄟ^(guò)運(yùn)行openRtsp模擬向服務(wù)器發(fā)出不同并發(fā)數(shù)，帶寬流量、訪問(wèn)媒體文件數(shù)等等，同時(shí)使用vlc實(shí)際播放流媒體，觀察流媒體播放質(zhì)量。最后我們就能從服務(wù)器收集不同條件下的服務(wù)器性能數(shù)據(jù)。為了分析簡(jiǎn)便直觀，我們把收集到數(shù)據(jù)導(dǎo)入到excel中并做成圖表進(jìn)行分析。

3.3　采集頻率的選定原則

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

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

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

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

4實(shí)驗(yàn)與性能分析

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

4.1　實(shí)驗(yàn)一

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

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

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

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

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

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

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

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

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

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

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

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

4.2　實(shí)驗(yàn)二

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

圖5　一個(gè)連接請(qǐng)求的CPU利用率及iowait百分比　

圖6　30個(gè)連接請(qǐng)求的CPU利用率及iowait百分比　

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

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

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

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

圖7　30個(gè)并發(fā)連接請(qǐng)求時(shí)，opfrofile收集的CPU使用信息 　

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

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

4.3　其他實(shí)驗(yàn)

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

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

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

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

5結(jié)論

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

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

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

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

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

參考文獻(xiàn)

[1]徐茂.流媒體服務(wù)器性能調(diào)優(yōu)關(guān)鍵點(diǎ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

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

收稿日期：2015-06-02

中圖分類號(hào)：TP37

文獻(xiàn)標(biāo)識(shí)碼：A

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