一種面向邊緣計算的可擴(kuò)展網(wǎng)絡(luò)I/O框架

宋平 畢立波

(中國信息通信研究院技術(shù)與標(biāo)準(zhǔn)研究所，北京 100191)

0 引言

邊緣計算在網(wǎng)絡(luò)邊緣提供了一種去中心化的計算和存儲方法。與傳統(tǒng)的云計算相比，邊緣計算可以在邊緣設(shè)備上分析、處理和使用采集的數(shù)據(jù)信息，無需將數(shù)據(jù)完全上傳到遠(yuǎn)端集中式服務(wù)器上進(jìn)行處理，從而滿足低時延、大帶寬和海量接入的需求。邊緣計算可以廣泛應(yīng)用于IoT、云游戲、實時音視頻分析、AR/VR等多種新興應(yīng)用場景。2016年，歐洲電信標(biāo)準(zhǔn)化協(xié)會(ETSI)提出“多接入邊緣計算(Multi-access Edge Computing，MEC)”，并將其定義為一種具備多種類型接入能力，能在網(wǎng)絡(luò)邊緣側(cè)提供IT服務(wù)環(huán)境和云計算能力的系統(tǒng)[1]。3GPP標(biāo)準(zhǔn)組織已將MEC作為網(wǎng)絡(luò)架構(gòu)的重要組成之一納入5G標(biāo)準(zhǔn)[2]。

部署在網(wǎng)絡(luò)邊緣的邊緣節(jié)點為海量邊緣用戶提供種類豐富的邊緣應(yīng)用。在該場景下，邊緣應(yīng)用需要充分利用邊緣計算的計算、存儲和網(wǎng)絡(luò)資源提供邊緣服務(wù)。邊緣應(yīng)用將同時執(zhí)行計算和網(wǎng)絡(luò)輸入和輸出(Input and Outpput, I/O)過程，處理海量邊緣用戶的請求。因此，邊緣應(yīng)用針對邊緣用戶請求的處理效率，是決定整個邊緣計算系統(tǒng)能否滿足低延時和海量接入需求的關(guān)鍵，而并發(fā)網(wǎng)絡(luò)I/O是邊緣應(yīng)用重要的組成部分，其效率對邊緣計算系統(tǒng)整體性能有著重要的影響。為了更及時地響應(yīng)數(shù)量更多的邊緣用戶，需要具有良好可擴(kuò)展性的支持高并發(fā)的網(wǎng)絡(luò)I/O模型。

傳統(tǒng)的并發(fā)網(wǎng)絡(luò)I/O模型包含多線程模型和事件驅(qū)動模型兩種，在實際應(yīng)用中現(xiàn)有解決方案大多使用事件驅(qū)動混合模型(Event-Driven Hybrid Model)。一些方案[3-6]擴(kuò)展了單線程的事件驅(qū)動模型，在多核環(huán)境下利用不同的線程運行獨立的事件循環(huán)；另一些解決方案[7-9]在基于事件的系統(tǒng)上，為每個網(wǎng)絡(luò)鏈接提供輕量級的線狀結(jié)構(gòu)進(jìn)行處理，在處理過程中隱式地控制輕量級線程的執(zhí)行狀態(tài)；第三種混合模型為多階段的事件驅(qū)動模型[10-12]，其處理過程由一系列的階段組成，不同的階段依靠事件隊列進(jìn)行通信。每個階段具有獨立的處理邏輯，在階段內(nèi)部使用搶占式的多線程并行處理事件隊列中的事件。不同的事件驅(qū)動混合模型在不同的應(yīng)用場景下各具優(yōu)勢。當(dāng)前高性能的邊緣節(jié)點通?？梢跃哂袛?shù)十個處理器核，然而由于數(shù)據(jù)沖突和負(fù)載不均衡等原因，當(dāng)前的事件驅(qū)動混合模型的處理性能可擴(kuò)展性存在瓶頸。

本文提出一種面向邊緣計算的可擴(kuò)展網(wǎng)絡(luò)I/O處理方法，解決在邊緣計算應(yīng)用場景下事件驅(qū)動混合模型的可擴(kuò)展性問題。該方法在事件驅(qū)動混合模型的基礎(chǔ)上，利用更多的線程監(jiān)聽網(wǎng)絡(luò)異步事件，使用開銷較低的任務(wù)竊取方法均衡線程之間的負(fù)載，并且根據(jù)工作線程的負(fù)載情況指導(dǎo)鏈接的分配，進(jìn)一步提高模型執(zhí)行效率。另外，針對事件處理過程中產(chǎn)生的數(shù)據(jù)競爭問題，本方法使用共享數(shù)據(jù)標(biāo)記的方式，將事件與特定的共享數(shù)據(jù)的處理方法進(jìn)行關(guān)聯(lián)，實現(xiàn)了事件處理過程中針對共享數(shù)據(jù)操作的提取，并且針對這些共享數(shù)據(jù)，可以使用額外的狀態(tài)線程進(jìn)行更細(xì)粒度的數(shù)據(jù)級并行，防止事件處理中的數(shù)據(jù)沖突阻塞網(wǎng)絡(luò)I/O。

1 邊緣計算基本框架

ETSI MEC工作組定義了多接入邊緣計算，并提出了如圖1所示多接入邊緣計算的基本框架[13]。該框架將邊緣計算從宏觀的角度劃分為系統(tǒng)層、主機(jī)層和網(wǎng)絡(luò)層。其中，系統(tǒng)層主要負(fù)責(zé)邊緣計算系統(tǒng)的全局管理和編排；主機(jī)層主要負(fù)責(zé)虛擬基礎(chǔ)設(shè)施管理、邊緣計算應(yīng)用管理和邊緣計算平臺管理等；網(wǎng)絡(luò)層主要提供無線網(wǎng)絡(luò)、本地網(wǎng)絡(luò)和其他外部網(wǎng)絡(luò)接入，使得海量邊緣用戶可以通過多種網(wǎng)絡(luò)協(xié)議接入邊緣計算系統(tǒng)。

圖1 多接入邊緣計算基礎(chǔ)框架

由圖1可見，MEC主機(jī)包含了虛擬基礎(chǔ)設(shè)施、MEC平臺和MEC應(yīng)用三部分。豐富的MEC應(yīng)用將運行于虛擬基礎(chǔ)設(shè)施上，為邊緣用戶提供不同的邊緣服務(wù)。虛擬基礎(chǔ)設(shè)施資源為MEC應(yīng)用提供了虛擬計算資源、虛擬存儲資源和虛擬網(wǎng)絡(luò)資源。MEC應(yīng)用之間依靠MEC平臺上安裝的轉(zhuǎn)發(fā)規(guī)格進(jìn)行流量轉(zhuǎn)發(fā)。

當(dāng)海量用戶通過網(wǎng)絡(luò)層接入邊緣計算系統(tǒng)后，主要由運行在MEC主機(jī)上的不同邊緣應(yīng)用處理邊緣用戶請求。當(dāng)前，邊緣計算解決方案主要通過虛擬機(jī)或容器的方式運行邊緣應(yīng)用，實現(xiàn)不同邊緣應(yīng)用之間的資源隔離。因此，邊緣應(yīng)用利用虛擬基礎(chǔ)設(shè)施提供的虛擬資源，針對海量邊緣用戶請求的處理效率，決定了整個邊緣計算系統(tǒng)能夠滿足低延時和海量接入的需求。

2 事件驅(qū)動混合模型

邊緣應(yīng)用在處理海量邊緣用戶請求時，需要綜合考慮計算和網(wǎng)絡(luò)I/O，提高應(yīng)用的執(zhí)行效率。在網(wǎng)絡(luò)I/O方面，基于事件驅(qū)動的混合模型主要強(qiáng)調(diào)利用事件編程的優(yōu)勢，使用多個線程或進(jìn)程并行地執(zhí)行不同的事件循環(huán)(Event Loop)，典型的方式是一個線程或進(jìn)程對應(yīng)一個事件循環(huán)，處理異步的網(wǎng)絡(luò)I/O事件和應(yīng)用級(Application-Level)事件。當(dāng)邊緣應(yīng)用使用更多的計算資源時，由于數(shù)據(jù)競爭和負(fù)載不均衡，將導(dǎo)致事件混合驅(qū)動的可擴(kuò)展性問題。

2.1 數(shù)據(jù)競爭問題

當(dāng)訪問共享數(shù)據(jù)時，當(dāng)前的多線程模型主要通過鎖或原子操作等方式保證數(shù)據(jù)一致性。然而這些同步方式容易導(dǎo)致多個線程發(fā)生數(shù)據(jù)競爭[14]。

Libasync-Smp[5]使用事件染色方法對一個事件類型相關(guān)的所有事件回調(diào)函數(shù)標(biāo)記不同的顏色，可解決數(shù)據(jù)競爭問題，對于具有相同顏色的事件回調(diào)函數(shù)使用同一個線程順序執(zhí)行，而對于具有不同顏色的事件回調(diào)函數(shù)則使用不同的線程并行執(zhí)行，從而避免不同事件處理過程中的數(shù)據(jù)沖突。然而，一個事件回調(diào)函數(shù)內(nèi)部可能存在多個共享數(shù)據(jù)操作，從而導(dǎo)致事件回調(diào)函數(shù)并行處理的并行度受限。

在Mace[15]提出的原子事件模型中，每個事件通過鎖機(jī)制保證該事件被原子地獨立地執(zhí)行，并且使用一個線程處理網(wǎng)絡(luò)I/O。該模型擴(kuò)展性有限，邊緣應(yīng)用難以利用更多資源處理海量用戶請求。為了解決該問題，InContext[4]通過對事件回調(diào)函數(shù)(Event Handler)標(biāo)記原子性，實現(xiàn)了更細(xì)粒度的并行。與事件染色方法的問題類似，被標(biāo)記為“全局”的事件處理方法在執(zhí)行過程中可能包含對多個共享數(shù)據(jù)的處理，從而限制了整體事件處理過程的可并行度。

2.2 負(fù)載不均衡問題

在事件驅(qū)動混合模型中，每個線程處理不同的邊緣用戶鏈接需要處理異步網(wǎng)絡(luò)I/O事件和對應(yīng)觸發(fā)的應(yīng)用事件，將導(dǎo)致不同邊緣用戶鏈接具有差別較大的處理時延。例如，在文件服務(wù)應(yīng)用中，用戶請求不同大小的文件，將導(dǎo)致不同的用戶處理開銷[16]。因此，為了提高邊緣應(yīng)用的處理效率，需要均衡應(yīng)用級事件處理負(fù)載和異步網(wǎng)絡(luò)I/O事件處理負(fù)載。

Beacon[3]使用了輪詢的方式為每個線程平均分配交換機(jī)鏈接，實現(xiàn)網(wǎng)絡(luò)I/O負(fù)載均衡。然而，由于該方式并未考慮應(yīng)用級事件處理的復(fù)雜度問題，導(dǎo)致負(fù)載不均衡問題依然存在。

Libasync-Smp和Mely使用基于時間染色的任務(wù)竊取算法均衡網(wǎng)絡(luò)I/O負(fù)載和網(wǎng)絡(luò)應(yīng)用負(fù)載。在該方法中，任務(wù)竊取的粒度為具有相同顏色的事件回調(diào)函數(shù)，具有相同顏色的事件回調(diào)函數(shù)無法被并行執(zhí)行，從而導(dǎo)致任務(wù)竊取過程具有較大的開銷。雖然Mely[6]使用多種竊取方式提高被竊取任務(wù)的執(zhí)行效率，但該任務(wù)竊取執(zhí)行過程依然非常復(fù)雜，較大的竊取開銷將降低甚至抵消平衡負(fù)載所帶來的性能提升。另外，Libasync-smp和Mely使用一個Select/Epoll 實例處理異步I/O方式，容易被其他應(yīng)用級事件阻塞，且性能較低[9]。

3 面向邊緣計算的可擴(kuò)展網(wǎng)絡(luò)I/O模型

本文面向邊緣計算場景，重點解決當(dāng)前網(wǎng)絡(luò)I/O模型存在的數(shù)據(jù)沖突和負(fù)載不均衡問題，提出一種可擴(kuò)展的網(wǎng)絡(luò)I/O模型。通過該模型，邊緣應(yīng)用可以充分利用邊緣節(jié)點的物理資源，滿足海量邊緣用戶低時延的處理需求。

如圖2所示，在本文提出的可擴(kuò)展I/O模型中，工作線程可以分為鏈接線程、I/O線程以及狀態(tài)線程3類。不同類型的線程之間協(xié)同工作，對不同的事件進(jìn)行并行處理。其中，處理的事件類型包括網(wǎng)絡(luò)I/O事件和上層的邊緣應(yīng)用事件，每個事件的處理邏輯由一系列的事件回調(diào)函數(shù)組成。在負(fù)責(zé)執(zhí)行事件處理邏輯的不同階段，I/O線程和狀態(tài)線程執(zhí)行不同的事件回調(diào)函數(shù)，具體分工如下。

圖2 面向邊緣計算的可擴(kuò)展網(wǎng)絡(luò)I/O模型

(1)鏈接線程：在本文提出的可擴(kuò)展I/O該模型中具有唯一的鏈接線程，該線程執(zhí)行一個循環(huán)(Loop)，實時地對到達(dá)的鏈接請求進(jìn)行監(jiān)聽；當(dāng)鏈接建立后，根據(jù)當(dāng)前I/O線程的負(fù)載情況分配該鏈接。

(2)I/O 線程：I/O線程負(fù)責(zé)監(jiān)聽、收發(fā)由鏈接線程(Connection Thread)分配的不同網(wǎng)絡(luò)鏈接消息，并且執(zhí)行部分事件處理邏輯。每個I/O 線程綁定一個本地事件隊列，隊列中保存著已就緒的異步網(wǎng)絡(luò)事件和上層應(yīng)用事件。另外，每個I/O線程通過一個特定的Epoll實例，對其所屬的網(wǎng)絡(luò)鏈接的消息進(jìn)行異步收發(fā)。在處理本地事件時，I/O 線程執(zhí)行一個循環(huán)，監(jiān)聽鏈接的異步事件，對到達(dá)的網(wǎng)絡(luò)消息進(jìn)行異步非阻塞的讀寫并且對觸發(fā)的事件進(jìn)行處理。在事件處理過程中，當(dāng)需要處理特定的共享數(shù)據(jù)時，I/O線程可以將該事件發(fā)送給處理該共享數(shù)據(jù)的狀態(tài)線程。與此同時，每個I/O線程負(fù)責(zé)對自身工作負(fù)載情況進(jìn)行統(tǒng)計。

(3)狀態(tài)線程：狀態(tài)線程僅負(fù)責(zé)對事件處理邏輯中全局共享數(shù)據(jù)的操作過程進(jìn)行并行處理。其中，每個狀態(tài)線程與特定的共享數(shù)據(jù)進(jìn)行關(guān)聯(lián)，順序執(zhí)行該共享數(shù)據(jù)的所有操作。對于不同的共享數(shù)據(jù)，則由不同的狀態(tài)線程進(jìn)行并行處理。當(dāng)執(zhí)行完某個事件的共享數(shù)據(jù)操作過程后，將該事件返回給原來的I/O線程或者其他狀態(tài)線程繼續(xù)執(zhí)行。

在圖2所示面向邊緣計算的可擴(kuò)展I/O模型基礎(chǔ)上，本文分別提出了共享數(shù)據(jù)標(biāo)記方法以及一種低開銷的任務(wù)竊取方法，以解決當(dāng)前網(wǎng)絡(luò)I/O模型的數(shù)據(jù)沖突和負(fù)載不均衡問題。

3.1 共享數(shù)據(jù)標(biāo)記方法

為了避免在事件處理過程中的數(shù)據(jù)競爭，本文將事件處理邏輯劃分為共享數(shù)據(jù)操作過程和非共享數(shù)據(jù)操作過程，其中在一個特定共享數(shù)據(jù)的操作過程中不能包含對其他共享數(shù)據(jù)的操作。如圖3所示，對于非共享數(shù)據(jù)操作過程，I/O線程可以高效地非阻塞地執(zhí)行。對于可能產(chǎn)生阻塞的共享數(shù)據(jù)操作過程，I/O線程將該事件處理過程交由狀態(tài)線程進(jìn)行處理。為了確保不會被數(shù)據(jù)競爭阻塞，I/O線程不會等待狀態(tài)線程的執(zhí)行，而將繼續(xù)處理本地隊列中的其他事件。當(dāng)狀態(tài)線程執(zhí)行完成后，會根據(jù)下一個事件處理過程的類型，將事件處理過程交給特定的線程繼續(xù)執(zhí)行。

圖3 異步共享數(shù)據(jù)處理過程

為了實現(xiàn)上述過程，本文提出了一種簡單的共享數(shù)據(jù)標(biāo)記方法。該方法通過將事件回調(diào)函數(shù)與特定的共享數(shù)據(jù)進(jìn)行關(guān)聯(lián)，實現(xiàn)對鏈接處理過程中共享數(shù)據(jù)的操作進(jìn)行提取。如果一個事件回調(diào)函數(shù)與一個特定的共享數(shù)據(jù)相互關(guān)聯(lián)，則表示該事件回調(diào)函數(shù)在執(zhí)行過程中除操作該共享數(shù)據(jù)外，不會對其他共享數(shù)據(jù)進(jìn)行操作。關(guān)聯(lián)共享數(shù)據(jù)的事件回調(diào)函數(shù)將由指定的狀態(tài)線程執(zhí)行。如果事件回調(diào)函數(shù)沒有和任何共享數(shù)據(jù)進(jìn)行關(guān)聯(lián)，則表示該事件回調(diào)函數(shù)在執(zhí)行過程中不會操作任何共享數(shù)據(jù)，可以直接由I/O線程執(zhí)行。

由于增加了線程間的通信時延，I/O線程與狀態(tài)線程協(xié)作處理共享數(shù)據(jù)的方式并不適用于所有的共享數(shù)據(jù)處理。例如，當(dāng)對一個共享數(shù)據(jù)操作的執(zhí)行時間很短，甚至小于線程間的通信時延時，多個I/O線程互斥地操作共享數(shù)據(jù)的方式具有更高的執(zhí)行效率。而共享數(shù)據(jù)標(biāo)記的方式依然適用于這種互斥的訪問方式。當(dāng)I/O線程執(zhí)行與共享數(shù)據(jù)關(guān)聯(lián)的事件回調(diào)函數(shù)時，首先判斷其執(zhí)行的方式，對于可能產(chǎn)生較長時間阻塞的事件回調(diào)函數(shù)，通過異步的方式將其交由狀態(tài)線程處理；反之，通過內(nèi)部鎖機(jī)制同步地執(zhí)行該事件回調(diào)函數(shù)。

區(qū)別于事件染色方法和原子事件模型，共享數(shù)據(jù)標(biāo)記方法是從共享數(shù)據(jù)的角度，對不同的事件回調(diào)函數(shù)進(jìn)行標(biāo)記。因此，在整體事件處理過程中，共享數(shù)據(jù)標(biāo)記方法可以使整個事件處理過程具有更高的并行度。

3.2 低開銷任務(wù)竊取方法

由于鏈接請求次數(shù)、事件處理邏輯的復(fù)雜度等原因，導(dǎo)致處理不同的邊緣用戶鏈接所需開銷不同。因此，在執(zhí)行過程中，工作線程間可能發(fā)生負(fù)載不均衡的現(xiàn)象，影響整體處理效率。例如，SFS文件服務(wù)應(yīng)用中不同用戶需求的文件大小不同，使得網(wǎng)絡(luò)鏈接傳輸?shù)臄?shù)據(jù)量存在差異[16]；SDN應(yīng)用中不同的流可能具有不同QoS需求，其路由過程具有不同的復(fù)雜度。為了均衡線程間的負(fù)載，本文從兩個方面動態(tài)地調(diào)節(jié)I/O線程之間的負(fù)載。

一方面，本文使用了具有較低開銷、較高執(zhí)行效率的任務(wù)竊取算法，動態(tài)地均衡I/O線程之間的負(fù)載。與Libasync-Smp及Mely提及的工作線程不同，面向邊緣計算的可擴(kuò)展I/O模型中的每個I/O線程不僅需要執(zhí)行本地事件隊列中的事件，還需要從底層操作系統(tǒng)獲取該線程所屬的網(wǎng)絡(luò)鏈接的異步事件。I/O線程會優(yōu)先執(zhí)行事件隊列中的事件，然后再嘗試獲取網(wǎng)絡(luò)異步事件。因此，面向邊緣計算的可擴(kuò)展I/O模型中I/O線程進(jìn)行任務(wù)竊取的觸發(fā)條件為I/O線程的本地事件隊列為空，且無異步的網(wǎng)絡(luò)事件。

在選擇被竊取線程后，竊取線程首先嘗試獲取被竊取線程所負(fù)責(zé)鏈接的異步網(wǎng)絡(luò)事件，如果有異步網(wǎng)絡(luò)事件則將這些事件放入受害者線程的本地事件隊列，并且執(zhí)行K個事件(K在模型初始化時設(shè)置)，否則嘗試獲取并執(zhí)行被竊取線程的本地事件隊列中的事件(最多K個)。如果本地隊列為空，則竊取失敗。

與基于事件染色的任務(wù)竊取算法不同，低開銷任務(wù)竊取方法在竊取任務(wù)時，I/O線程無需考慮事件回調(diào)函數(shù)之間的數(shù)據(jù)沖突問題，具有較低的竊取開銷。與此同時，該方法還可以幫助負(fù)載較重的線程獲取異步網(wǎng)絡(luò)事件，服務(wù)更多的網(wǎng)絡(luò)鏈接。

另一方面，與現(xiàn)有模型所使用的輪詢方式不同，面向邊緣計算的可擴(kuò)展I/O模型在分配網(wǎng)絡(luò)鏈接時，鏈接分配線程優(yōu)先從全局的空閑線程隊列中選擇負(fù)載較輕的線程，為其分配鏈接。該方式可以使網(wǎng)絡(luò)鏈接更加及時地得到響應(yīng)。在面向邊緣計算的可擴(kuò)展I/O模型初始化階段，全局空閑線程隊列中保存所有的I/O線程號。當(dāng)新的鏈接到達(dá)時，從該隊列頭部取出一個線程號進(jìn)行分配。在面向邊緣計算的可擴(kuò)展I/O模型執(zhí)行過程中，負(fù)載較輕的I/O線程會動態(tài)地將自己的線程號放入全局空閑線程隊列的尾部。如果全局空閑線程隊列為空，則使用輪詢的方式分配網(wǎng)絡(luò)鏈接。

面向邊緣計算的可擴(kuò)展I/O模型中每個I/O線程的任務(wù)竊取次數(shù)反映了每個I/O線程的負(fù)載情況。由于網(wǎng)絡(luò)應(yīng)用中每個任務(wù)的執(zhí)行時間通常很短，因此，任務(wù)個數(shù)可以在一定程度上反映任務(wù)量。線程在進(jìn)行任務(wù)竊取時，會統(tǒng)計已執(zhí)行的任務(wù)數(shù)量(竊取的任務(wù)數(shù)NSteal、所屬鏈接的任務(wù)數(shù)NConn及當(dāng)前剩余任務(wù)數(shù)量NR算一個綜合的工作負(fù)載W(0

(1)

當(dāng)鏈接分配線程分配一個新鏈接給I/O線程時，將該線程的NSteal設(shè)置為0。因此，NSteal+NConn為從分配新的鏈接開始到每次任務(wù)竊取發(fā)生時，該I/O線程已處理任務(wù)的總個數(shù)。每次任務(wù)竊取前后，剩余任務(wù)數(shù)量NR發(fā)生變化。NSteal+NConn+NR表示從分配新的鏈接開始到每次任務(wù)竊取結(jié)束的總?cè)蝿?wù)個數(shù)。W表示NSteal任務(wù)個數(shù)在總?cè)蝿?wù)個數(shù)中占有的比例。

4 試驗

Web服務(wù)器應(yīng)用可以部署在邊緣節(jié)點，為邊緣用戶提供豐富的Web服務(wù)。本章通過Web服務(wù)器應(yīng)用驗證可擴(kuò)展網(wǎng)路I/O模型的執(zhí)行效率。本文利用網(wǎng)絡(luò)I/O模型實現(xiàn)一個HTTP服務(wù)器，該程序通過頻繁地創(chuàng)建網(wǎng)絡(luò)鏈接服務(wù)大量的客戶，針對每個請求執(zhí)行一個不存在數(shù)據(jù)競爭的事件處理過程。

Web服務(wù)器應(yīng)用運行在一臺24核32 G內(nèi)存的四路Intel Xeon服務(wù)器上，每路服務(wù)器有一個Intel(R) Xeon(R) E7-4087處理器，每個處理器包含6個處理器核，主頻為1.87 GHz。此外，該服務(wù)器還有一個雙端口Intel 10G網(wǎng)卡。該服務(wù)器上運行的系統(tǒng)軟件包括：Linux系統(tǒng)RedHat 6.2、Linux內(nèi)核版本Linux2.6.32、Linux 系統(tǒng)gcc編譯器版本gcc-4.4.7。本文使用兩臺普通PC機(jī)作為測試機(jī)，每個測試機(jī)具有1個10 Gbit/s端口。測試機(jī)和服務(wù)器通過一臺華為交換機(jī)連接。

為了驗證Web服務(wù)器應(yīng)用可以更好地利用服務(wù)器物理資源，本文針對已緩存負(fù)載的Web服務(wù)器進(jìn)行測試。測試機(jī)端使用Httperf 工具進(jìn)行測試[17]。Httperf是一個HTPP服務(wù)器性能測試工具，用于模擬壓力負(fù)載。

本章首先針對100 KB的小文件進(jìn)行I/O可擴(kuò)展性測試。在服務(wù)器端，本文分別運行了3個運行時：使用任務(wù)竊取的面向邊緣計算的可擴(kuò)展I/O模型、不使用任務(wù)竊取的面向邊緣計算的可擴(kuò)展I/O模型以及使用任務(wù)竊取的Mely。每個工作線程與CPU綁定，通過調(diào)整線程個數(shù)，測試模型運行時的吞吐量。為了測試任務(wù)竊取的有效性，本文手動調(diào)整面向邊緣計算的可擴(kuò)展I/O模型中不同線程的負(fù)載，分配鏈接時按照2:1的比例為不同的線程分配鏈接。在測試端，兩臺測試機(jī)運行4個Httperf，每個Httperf模擬3萬個并發(fā)用戶請求，計算每秒服務(wù)的請求個數(shù)，每個用戶在鏈接關(guān)閉前發(fā)送1個請求。針對小文件的網(wǎng)絡(luò)I/O可擴(kuò)展性測試結(jié)果如圖4所示。

圖4 針對小文件的網(wǎng)絡(luò)I/O可擴(kuò)展性測試結(jié)果

由圖4可見，當(dāng)線程個數(shù)為1時，使用任務(wù)竊取和不使用任務(wù)竊取的面向邊緣計算的可擴(kuò)展I/O模型具有相似的處理效率，并且處理效率略低于Mely模型。但是，隨著線程個數(shù)的增長，相比于不使用任務(wù)竊取的面向邊緣計算的可擴(kuò)展I/O模型和Mely模型，使用任務(wù)竊取的面向邊緣計算的可擴(kuò)展I/O模型具有更高的處理效率。

此外，本文針對大小不同的文件集進(jìn)行了測試。這些文件集根據(jù)SPECweb2009 Benchmark生成，共300 MB，其文件大小符合Zipf分布[18]。本文還在測試機(jī)上運行了Httperf，觀察、對比了不同數(shù)量的并發(fā)用戶下不同服務(wù)器的帶寬占用情況。因每個用戶在一個鏈接結(jié)束前產(chǎn)生10次請求，本文按每次測試持續(xù)60 s的頻率測量了服務(wù)器在穩(wěn)定狀態(tài)下的吞吐帶寬情況。在服務(wù)器端，本文使用了12個線程，分別運行了Mely、Apache[19]以及使用任務(wù)竊取和不使用任務(wù)竊取的面向邊緣計算的可擴(kuò)展I/O模型。

圖5展示了不同數(shù)量的并發(fā)用戶下的測試結(jié)果?？梢钥闯觯S著用戶數(shù)量的增長，面向邊緣計算的可擴(kuò)展I/O模型的處理性能持續(xù)增長，具有更高的可擴(kuò)展性。雖然Apache模型下增長的速度比本模型快，但是其很快就達(dá)到了性能峰值；Mely模型下的處理性能在整體上要低于面向邊緣計算的可擴(kuò)展I/O模型和Mely模型。使用任務(wù)竊取的面向邊緣計算的可擴(kuò)展I/O模型與不使用任務(wù)竊取的面向邊緣計算的可擴(kuò)展I/O模型具有相似的處理性能，主要原因是這二者都采用平均分配鏈接地的方式，線程間負(fù)載非常均衡，使得任務(wù)竊取影響較小。

圖5 針對大文件的并發(fā)用戶測試結(jié)果

5 結(jié)束語

本文首先介紹了邊緣計算的基礎(chǔ)架構(gòu)，然后重點分析了在邊緣計算場景下，網(wǎng)絡(luò)I/O模型存在的可擴(kuò)展性問題，并提出了面向邊緣計算的可擴(kuò)展網(wǎng)絡(luò)I/O模型，最后通過Web應(yīng)用試驗，驗證了本文提出的網(wǎng)路I/O模型具有良好的可擴(kuò)展性。利用該模型，邊緣應(yīng)用可以更好地利用邊緣節(jié)點物理資源，為海量邊緣用戶提供低時延的服務(wù)。