基于P2P和CDN的監(jiān)控傳輸子系統(tǒng)的設(shè)計
當客戶在邊緣服務器上請求資源不命中時,邊緣服務器會向原始服務器請求,原始服務器會根據(jù)具體請求要求,將需要的媒體資源通過該文實現(xiàn)的高效傳輸子系統(tǒng)存儲在本地,然后利用P2P的方式向多個邊緣服務器發(fā)布內(nèi)容。
通過這種方式有效減輕了原始服務器在內(nèi)容發(fā)布時的壓力。理論上它只要將一個完整的媒體副本發(fā)送出去,其他邊緣服務器會根據(jù)P2P的方式得到一個完整的副本。同理,當邊緣服務器向客戶提供服務時,理論上它也只需要傳輸一個副本,多個客戶端就可以得到完整的服務。原始服務器和媒體資源服務器通常是在一個子網(wǎng)中,網(wǎng)絡速度比磁盤I/O速度更快。此時,磁盤I/O成了系統(tǒng)的瓶頸。為了緩解網(wǎng)絡I/O和磁盤1/O的矛盾,在傳輸子系統(tǒng)的設(shè)計當中采用半同步/半異步的方式將網(wǎng)絡I/O與磁盤I/O分離開,并通過任務池的方式進行緩沖。
上層的主線程處理epoll異步事件和協(xié)議交互,框架將接收到的數(shù)據(jù)按照固定大小封裝在任務里面,然后將任務放回任務池,下層線程池負責從任務池中取出任務,進行具體的磁盤讀寫操作,操作完成后線程和任務分別回到線程池和任務池等待調(diào)度。
3 算法實現(xiàn)
為了對線程池進行有效的動態(tài)管理,需要采集各種性能參數(shù),經(jīng)過綜合分析之后,對線程池做出調(diào)整。該算法中參考了兩個最關(guān)鍵的參數(shù),即任務的平均等待時間和CPU使用率。通過任務的平均等待時間,可以分析得到當前線程池需要調(diào)整的方向。通過CPU使用率可以得到是否需要增加或者減少線程。
圖2中c(current)表示線程池當前平均等待時間;p(previous)表示線程池上次等待時間;pp表示上上次等待時間;ps(pool size)表示線程池大??;pps表示上次線程池大小。該算法中并不是對等待時間的絕對值進行比較,而是對currTime和preTime進行比較,如果差異大于1%,線程池可能需要調(diào)整,調(diào)整方向需要根據(jù)currTime和preTime的大小關(guān)系來決定。如果currTime大于preTime,需要進一步比較pre-Time和prepreTime的關(guān)系;如果preTime小于prepreTime,并且CPU使用率大于90%,那么減小線程池。減小的步長(stride)為2。如果preTime大于prepreTime,并且CPU使用率小于80%,則增大線程池,增加的步長為2。如果currTime小于preTime,并且preTime小于prepreTime,則增大線程池。
簡而言之,算法通過對currTime,preTime,prepre-
Time三者的關(guān)系進行比較,確定線程池是否需要調(diào)整。
當需要減小線程池時,需要進一步判斷CPU的使用率,只有CPU大于一個閥值時才進行減小操作,因為CPU的負載太小也是一種資源浪費;同理,當需要增大線程池時,也只能在CPU小于一個閥值時,才能進行增加操作,因為CPU的負載不能過大。
4 實驗分析
因為媒體資源服務器和原始服務器多在同一個子網(wǎng)中,因此實驗的環(huán)境也通過一個局域網(wǎng)模擬,服務器的基本配置是:兩個Intel雙核Xeon 3 GHz芯片、2 048 KB緩存、4 GB內(nèi)存、1 000 Mb/s網(wǎng)卡。
4.1 三種模型的實驗數(shù)據(jù)
p2p機相關(guān)文章:p2p原理
評論