當客戶在邊緣服務器上請求資源不命中時，邊緣服務器會向原始服務器請求，原始服務器會根據具體請求要求，將需要的媒體資源通過該文實現的高效傳輸子系統存儲在本地，然后利用P2P的方式向多個邊緣服務器發布內容。
通過這種方式有效減輕了原始服務器在內容發布時的壓力。理論上它只要將一個完整的媒體副本發送出去，其他邊緣服務器會根據P2P的方式得到一個完整的副本。同理，當邊緣服務器向客戶提供服務時，理論上它也只需要傳輸一個副本，多個客戶端就可以得到完整的服務。原始服務器和媒體資源服務器通常是在一個子網中，網絡速度比磁盤I／O速度更快。此時，磁盤I／O成了系統的瓶頸。為了緩解網絡I／O和磁盤1／O的矛盾，在傳輸子系統的設計當中采用半同步／半異步的方式將網絡I／O與磁盤I／O分離開，并通過任務池的方式進行緩沖。
上層的主線程處理epoll異步事件和協議交互，框架將接收到的數據按照固定大小封裝在任務里面，然后將任務放回任務池，下層線程池負責從任務池中取出任務，進行具體的磁盤讀寫操作，操作完成后線程和任務分別回到線程池和任務池等待調度。

3 算法實現
為了對線程池進行有效的動態管理，需要采集各種性能參數，經過綜合分析之后，對線程池做出調整。該算法中參考了兩個最關鍵的參數，即任務的平均等待時間和CPU使用率。通過任務的平均等待時間，可以分析得到當前線程池需要調整的方向。通過CPU使用率可以得到是否需要增加或者減少線程。

圖2中c(current)表示線程池當前平均等待時間；p(previous)表示線程池上次等待時間；pp表示上上次等待時間；ps(pool size)表示線程池大小；pps表示上次線程池大小。該算法中并不是對等待時間的絕對值進行比較，而是對currTime和preTime進行比較，如果差異大于1％，線程池可能需要調整，調整方向需要根據currTime和preTime的大小關系來決定。如果currTime大于preTime，需要進一步比較pre-Time和prepreTime的關系；如果preTime小于prepreTime，并且CPU使用率大于90％，那么減小線程池。減小的步長(stride)為2。如果preTime大于prepreTime，并且CPU使用率小于80％，則增大線程池，增加的步長為2。如果currTime小于preTime，并且preTime小于prepreTime，則增大線程池。
簡而言之，算法通過對currTime，preTime，prepre-
Time三者的關系進行比較，確定線程池是否需要調整。
當需要減小線程池時，需要進一步判斷CPU的使用率，只有CPU大于一個閥值時才進行減小操作，因為CPU的負載太小也是一種資源浪費；同理，當需要增大線程池時，也只能在CPU小于一個閥值時，才能進行增加操作，因為CPU的負載不能過大。

4 實驗分析
因為媒體資源服務器和原始服務器多在同一個子網中，因此實驗的環境也通過一個局域網模擬，服務器的基本配置是：兩個Intel雙核Xeon 3 GHz芯片、2 048 KB緩存、4 GB內存、1 000 Mb／s網卡。
4．1 三種模型的實驗數據