基于事件驅動和ＱｏＳ控制的Ｗｅｂ服務器體系結構

（南京大學 計算機科學與技術系， 南京 210093）

摘 要：

Web服務器在滿足大量且不斷上升的用戶需求方面扮演著關鍵角色，但Web服務器也面臨高并發的用戶請求、不同的QoS需求和訪問控制等眾多挑戰。針對這些挑戰提出了一種采用事件驅動和QoS控制的新型Web服務器體系結構，并依此開發出命名為Epdds的原型服務器。通過對Epdds服務器的性能分析及與其他Web服務器性能對比，進一步驗證了此種Web服務器體系結構的可行性和有效性。

關鍵詞：事件驅動; 服務質量;體系結構; Web服務器

中圖分類號：TP393文獻標志碼：A

文章編號：1001-3695(2009)04-1327-04

Event-driven Web server architecture based on QoS control

WANG Ping-tao， XU Man-wu， TAN Jian

(Dept. of Computer Science Technology， Nanjing University， Nanjing 210093， China)

Abstract:

The perform of Web servers played a key role in satisfying the needs of a large and growing community of Web users， but Web servers met many challenges such as highly concurrent requests， different QoS requirements and admission control. This paper presented a new portable event-driven Web server architecture providing differentiated services to clients with different QoS requirements in order to solve above challenges， and evaluated the performance of an implementation of this architecture， the Epdds Web server. The performance of Epdds was compared with two widely-used Web servers， Apache and Zeus. Results indicate that Epdds can match or exceed the performance of existing Web servers by up to 10% across a wide range of workloads. The results show the feasibility and profitability of this architecture.

Key words：event-driven; QoS; admission control; Web server

0 引言

Web服務器作為上網用戶獲得信息的主要手段，容易因為用戶訪問擁塞或遭到攻擊而造成不可訪問，這種攻擊常常從互聯網的多個站點同時發起。拒絕服務攻擊往往對Web服務器的性能有較大的影響。在用戶訪問頻繁的網站，Web服務器的會話并發數量和每天點擊率造成大量的I/O吞吐和資源需求，而傳統的操作系統和通常的并發模型不能對高并發的用戶請求進行良好的管理。目前常用的操作系統采用進程或線程的方式處理并發，但是這種機制在進程間通信和進程上下文切換上需要較大的開銷。如何處理Web請求的高并發性是Web服務器面臨的挑戰之一。

隨著Internet變得越來越商業化和構架在Web服務器上的應用種類越來越多，Web服務器的可訪問性變得越來越重要，同時不同的上網用戶對架構在Web服務器上的不同應用有不同的QoS需求。Bhatti等人[1]指出了Web服務器QoS機制去支持多個服務層次和過載管理的重要性。目前Web服務器對所有用戶請求采取相同的處理方法，不能根據用戶或請求的類別來提供相應的QoS。特別是當客戶有不同的QoS需求或希望通過付出額外的代價來獲得他們期望的QoS時，Web服務器就應該把客戶分為多個類別并提供不同的QoS。對用戶來說，最基本的服務要求就是服務延遲問題，不同用戶對服務延遲有不同的要求。例如，進行網上股票交易要比瀏覽新聞的QoS要求高；在視頻點播業務中不同用戶可能會有不同的QoS要求。區別對待不同用戶或不同應用類別的用戶請求是Web服務器面臨的又一挑戰。

文獻[2]指出，由于HTTP請求經常以爆發的方式到達Web服務器，高峰時HTTP請求率超過平均值的8~10倍，這時的負載一般超過服務器的負載能力，使許多請求被Web服務器拒絕。在HTTP請求到達高峰時經常會造成Web服務器的不可訪問，從而降低用戶對該網站的信任，造成用戶的流失。如果依照高峰訪問量來配置Web服務器的軟硬件將會造成資源的極大浪費，畢竟Web服務器的訪問過載常常是短暫現象。因此，如何更好地對Web服務器進行訪問控制也是Web服務器面臨的挑戰之一。

為解決以上問題，本文提出了一種新型的可進行訪問控制的基于事件驅動和QoS控制的Web服務器體系結構。

1 事件驅動和QoS控制

通過對現有的Web服務器體系結構的研究分析，以提高Web服務器的可用性和有效性為目的，本文提出了一種新型的Web服務器體系結構。這種體系結構結合多進程（線程）和事件驅動各自的優點，采用一個主線程和少量輔線程的非對稱多線程的事件驅動方式來解決高并發的用戶請求問題，這樣能使Web服務器在不會被磁盤操作等I/O事件阻塞的情況下高效處理請求。采用WTP（等待時間優先）算法調度等待隊列中的請求，可以為不同的用戶請求提供延遲有差異的QoS，并保證不同類別請求的QoS差異能滿足預期的固定比率。為解決Web服務器的短暫過載現象，根據不同類別的請求特征（如到達速度、最大延遲時間等）對請求進行訪問控制，并按比例降低各類別請求服務的QoS。

1.1 事件驅動

由于基于事件驅動的系統一般采用少量的線程處理請求，這需要每一個操作應該是快速的和非阻塞的，事件驅動系統通常利用異步I/O方式。筆者對同步或異步方式的性能作了測試比較，測試內容為每一個用戶向欲連接的服務器發出一個8 KB的分組字符包，服務器對每一個用戶應答一個32 Byte的正確應答。測試采用的服務器為通過百兆以太網連接的、運行RedHat 9.0的微機服務器。如圖1所示，異步I/O方式采用/dev/poll機制進行數據傳輸，性能的下降受限于網絡的帶寬；而同步I/O方式采用線程池模仿進行異步處理，操作系統為每一個套接字分配一個線程。由于Linux的限制，線程的規模不能超過400個，隨著連接的增加性能下降很快。事件驅動方式的主要優點就是相比較重量級的線程切換而言，降低了線程間切換的開銷。事件驅動系統的開銷在隨著請求數量的增加造成管道飽和及發生資源瓶頸的情況下才顯著增加。如果設計正確，事件驅動方式能支持非常高的并發數，且隨著負載的增加性能下降較小。

1.2 QoS控制及訪問控制

本文提出了一種能按比例提供差異QoS的Web服務器Epdds。詳細地講，在Epdds服務器中，如果存在N > 1類用戶請求，對于i=2，3，…，N來說，第i類請求將得到比i-1類請求更好的服務性能。筆者將一個請求到達隊列后直到執行前在隊列中等待的這段時間稱為請求等待時間，用每類請求的平均等待時間作為衡量服務優劣的標準，將Wi表示第i類請求的平均等待時間。Epdds試著使第i類和第i-1類請求的平均等待時間保持固定的比率ri，i-1=Wi/Wi-1。例如，如果ri，i-1=0.5，表示第i類請求在隊列中的平均等待時間是第i-1類請求的1/2，也就是i類請求的處理速度是i-1類的兩倍。本文主要考慮實現以下目標：

a）不同類別請求QoS不依賴于負載裝入。

b）不同類別請求QoS差異可以控制。

c）系統接收的請求能夠在允許的最大延遲時間內完成。

本文是通過采用WTP調度算法來達到以上目標的。WTP調度算法是L.Kleinrock[3]在1964年首先發表的，當時命名為TDP（time-dependent priorities）。WTP調度算法是一個基于時間的優先級調度算法，一個請求的優先級隨著等待時間的增加而相應增加。在隊列中等待的請求在時間t的優先級為

Pi(t)=Wi(t)δi(1)

這里，Wi(t)是請求在時間t時的等待時間，差異QoS控制參數{δi}決定不同類別請求的處理速度。其中δ1<δ2<…<δN。從式（1）可知，如果每類請求歸入一個隊列，每個隊列中請求按到達先后排序，則每個請求隊列的首位請求優先級最大。因此當Web服務器準備在某個時間t調用某個請求時，它比較各個隊列中的首位請求，選擇請求j當：

j=arg max{Pi(t)}i=1，…，N，Ni(t)＞0(2)

其中j是在隊列中優先級最高的請求。如果隊列中沒有請求等待，服務器空閑并等待被新到請求激活。從WTP調度算法可以得出，當i類優先級小于j類時，由于差異QoS控制參數δi<δj，第j類請求將會得到比第j類請求更快的處理速度，因此j類請求的平均等待時間小于i類。

用λi表示第i類請求的到達速率，讓Wi表示第i類請求的平均等待時間，λ=∑Ni=1λi是系統的總到達速率。假設存在能實現各類請求平均等待時間按比例差異QoS的調度規則

Wi/Wj=δi/δj i，j=1，…，N（3）

假設按比例的差異QoS是可以調度的，根據守恒法則[3]可以得出：

∑Ni=1λiWi=∑Ni=1λiW(λ)（4）

其中：W(λ)表示FCFS(先來先服務)服務器的平均等待時間，FCFS服務器是連續工作型的，且與按比例差異QoS服務器具有相同的性能和總請求流量。從最小法則可知，守恒法則指出連續工作型系統的平均任務積累與調度規則無關，W(λ)主要依賴請求流量特征，需要對實際動態請求流量進行詳細的測量。基于式（1）和（3），本文定義δ1=1和δi=δi-1/ri-1，i；i=2，…，N。可知ri-1，i = Wi-1/ Wi，因而

δi=Wi/W1 i=2，…，N（5）

將式（5）帶入（4）可得

（Wi/δi）∑Nk=1λkδk =∑Nk=1λkW(λ)

經過變換可得

Wi=δi(∑Nk=1λk)W(λ)/∑Nk=1δkλki=1，…，N（6）

從式（6）可以得出按比例差異QoS調度算法的下列屬性：

a）所有類的平均等待時間隨著任一類請求到達率的增加而增加。

b）較高類別請求到達率的增加造成的平均等待時間增加比較低類別請求增加造成的大。

c）某一類請求的差異QoS控制參數增加會造成其他類請求的平均等待時間增加，而本類的平均等待時間減小。

從一個類的平均等待時間不能低于在FCFS服務器中的平均等待時間可知，按比例差異QoS的調度算法并不總是可行的。文獻 [4]給出了各類平均延遲可行性調度的充分必要條件，N類平均延遲是可行的當且僅當下列2N個不等式成立：

∑iλiWi≥(∑i∈λi)W(λ)，對于所有的∈Φ

這里Φ是{1，2，…，N}的2N-2非空完全子集的其中之一。W(λ)是用連續工作型FCFS服務器測試類∈Φ的總請求流量而得到的隊列平均等待時間。如果已知各類請求的到達率和整個服務器請求的平均等待時間，且連續工作型服務器取得式（6）所得的平均等待時間同時也滿足式（4），就可以說存在一套可行的差異QoS控制參數{δi}。雖然系統在一定的條件下不能得到預期的類別差異QoS，但當系統的利用率接近100%時，WTP調度算法能夠達到預期的延遲比率。當系統的利用率低時，各類請求都會被快速處理，不會造成請求在隊列中等待時間過長，因此無須對各類請求的QoS進行控制。從式（6）中還可以得出，如果某一個i類請求的最大延遲時間不大于Wi，系統就可以接收此請求；反之則拒絕。

2 系統的體系結構

針對解決前面提出的Web服務器面臨的高并發、QoS需求和系統過載時訪問控制等問題，筆者提出了一種新型的基于事件驅動和能夠提供QoS需求和訪問控制的Web服務器體系結構。如圖2所示，這種Web服務器體系結構可以看做是執行一個Web請求基本步驟的狀態機。Web服務器采用一個主線程和少量輔線程處理用戶請求。主線程處理Web請求的大部分操作， Web服務器采用異步方式接收用戶請求。當Web服務器收到用戶請求時，根據系統預先確定的不同類別QoS差異的固定比率和系統的負載情況計算出本類請求的平均延遲時間。如果此請求的最大延遲時間大于平均延遲時間，則接收此用戶請求并放入相應隊列中；否則拒絕。當主線程可用時，事件調度程序根據WTP調度算法計算各個隊列中處于就緒狀態的首請求的優先級，選擇優先級最大的請求交由主線程進行處理。當必須進行磁盤操作時，主線程通過進程間通信（IPC）調用輔線程執行可能的阻塞操作，主線程返回重新選取另一任務。輔線程一旦操作完成，就通過IPC返回一個通知，提醒主線程可以安全處理文件而不用擔心有被阻塞的危險。主線程就可以繼續進行后繼操作，直到請求完成。



基于事件驅動和能夠提供QoS需求和訪問控制的Web服務器體系結構具有以下特點：

a)非對稱多線程。不同體系結構的Web服務器對磁盤操作方法不盡相同。在多進程（線程）服務器中，只有進程才能阻塞磁盤活動，而非對稱多線程中輔線程通常用來進行容易引起阻塞的磁盤操作。由于主線程只處理請求有關的主要操作、少量輔線程處理與磁盤等I/O接口有關的操作，這樣既采用了事件驅動的高效并發處理，又避免由于資源競爭造成的阻塞現象。當輔線程被阻塞時，Web服務器仍能利用主線程處理其他請求，只不過增加了主、輔線程之間進程間通信的額外開銷。由于輔線程主要處理并發的磁盤操作，有很少的內存需求，與多進程為每一個請求分配一個進程相比，非對稱多線程消耗的內存要小得多。

b)QoS控制。在本Web服務器體系結構中通過WTP調度算法進行請求調度，不同類別的QoS差別是固定的，且QoS差別不依賴于各類請求的負載情況。Web服務器的操作員能指定和控制不同類別請求的QoS差別，通過調整QoS差異控制參數控制不同類別用戶請求的處理速度，保證級別較高的用戶請求能得到較快的響應。在Web服務器出現短暫過載時，各個類別請求的平均等待時間按比例增加，服務質量仍能保持相對固定。

c)訪問控制。通過對比每個請求的最大延遲時間和本類請求的平均延遲時間相比，確定Web服務器是否接收該請求。對通過訪問控制測試的請求歸入相應隊列，未接收的請求返回一個友好的提示，這樣既可以保證已接收請求正常完成，同時也避免了被拒絕請求長久等待后仍不能得到滿意的服務。

3 性能評測

3.1 QoS控制測試

在這部分實驗中，本文設定Epdds Web服務器支持兩類請求a和b，訪問Epdds的兩類請求的到達率為λa=0.4和λb=0.6;a類請求的最大等待時間在[1.5~3.5] s，b類請求在[2，3] s，它們的等待時間差異為ra，b=0.6或0.8。設置Epdds的取樣時間區間為100 s，隊列長度的初始值為1 000。從圖3測試結果可知，當系統的利用率低時，實際的ra，b與理想的ra，b有比較大的偏差；隨著利用率的增加，實際的ra，b與理想的ra，b逐漸一致。當利用率超過70%時，兩者基本一致。這說明在系統負載較重的情況下，Epdds Web服務器可以達到對QoS進行控制的目標。



3.2 性能對比

為了評估設計的Web服務器體系結構的具體性能，筆者用Java語言開發了一個原型系統Epdds Web服務器，并對Epdds的性能進行了測試。測試建立在一個有一臺IBM微機服務器、兩臺微機通過100 Mbps以太網交換機的網絡環境中。微機服務器為PⅢ 733、512 MB內存，操作系統是Red Hat 9.0，Java運行平臺為JDK1.4.0，微機主要配置為P4 1.2 GHz、1 GB內存。為模仿客戶請求，選用Httperf[4]作為性能測試工具，Httperf可以產生大小從102~921 600 Byte的Web頁面文件，Web頁面文件共計2.03 GB。為了進行性能對比，筆者配置了Zeus[5]、Apache（版本為1.3.26）兩種Web服務器。Apache是占主導地位的基于進程的Web服務器；Zeus是一個典型的事件驅動的、單線程Web服務器。Apache通過動態增加或減少線程池的線程來滿足不斷變化的并發用戶的連接要求；每一個進程接收一個用戶連接并處理該連接的所有操作，Zeus用單線程來執行請求的大多數操作。Zeus和Apache都是用C語言開發的，而Epdds是用Java編寫的。

Httperf可以在一臺微機上利用多線程機制模仿產生多個真實的用戶請求，在兩臺微機上模仿產生1 000個并發連接，每秒鐘產生50個并發連接。本文設置Apache最大用戶數為256，每個請求的最大反應時間為15 s。設置Epdds的取樣時間區間為100 s，隊列長度的初始值為1 000。



圖4(a)顯示在用戶數為1 000的情況下，訪問大小在50~1 000 Byte范圍的文件時，Epdds和Zeus提供超過Apache 15%~20%的吞吐量；在文件大于10 000 Byte后，三者的吞吐量基本相同。從圖4(b)系統吞吐量與連接用戶數的關系可以看出，Epdds的吞吐量相比于Apache和Zeus來說，大約超過另兩種服務器吞吐量的10%，三種服務器都在負載不斷增加的情況下保持了較高的吞吐量。

對測試數據進行分析可以得出，在用戶數不變的情況下，當訪問的文件較小時，由于被訪問內容可以緩存在內存中，基于事件驅動的服務器處理能力要高于采用多線程方式的服務器。在被訪問內容超過可用內存容量后，三種服務器的吞吐量基本相同。在訪問內容大小不變的情況下，在用戶數小于256時，三者的性能不相上下，隨著用戶數超過256，Apache吞吐量趨于穩定，而另兩種服務器的吞吐量也由于受網絡帶寬的限制趨于穩定。但因為連接用戶數超過Apache的線程數，造成有的用戶需要等待才能建立新連接，會使一些連接的反應時間過長，有效訪問用戶數逐漸下降。對于Epdds來說，當系統資源趨于飽和時，通過訪問控制來控制系統接受的用戶訪問數，使Epdds保持穩定狀態，以免造成系統因過載而發生錯誤或崩潰。

4 相關背景

目前Web服務器采取不同的方式處理并發性請求，從體系結構上可以分為進程和事件驅動兩類。采用事件驅動體系結構的Web服務器能夠非常好地處理大多數訪問緩存在內存內容的用戶請求，Zeus[5]、Flash[6]和SEDA[7]是這種體系結構的代表。當用戶請求的內容大小超過Web服務器的緩存能力時，采用多線程體系結構的Web服務器性能非常出色。主流的Web服務器如Apache、微軟的IIS和Sun的iPlanet都采用多線程的體系結構，這些Web服務器以及Bea WebLogic、IBM WebSphere等Web應用服務器都采用每任務分配一個線程的方式進行請求處理。在這種方法中，每個請求被分配一個有數量限制的線程池中的線程，而當所有的線程都忙時，新到請求就會被拒絕；在系統過載時會導致客戶的連接請求（SYN包）被服務器扔掉。由于TCP采用指數增長過時的方法轉發連接請求，這種方法可能會造成客戶長時間的等待—連接被建立或拋棄前需要幾分鐘的重試連接。這種方法也會造成對客戶訪問的不公平性，一些客戶的請求碰巧被接收，而其他的則需要忍受時間的煎熬。因此，雖然線程的方法得到了廣泛的應用，但仍存在幾個嚴重的問題：a）合適的線程池規模。大多數系統靜態地限定了最大線程數量，而線程數設置過低不能充分利用系統資源，過高會造成在負載過重情況下的服務性能下降。b）合適的線程生命周期。由于大多數系統采用靜態的線程生命周期，如果每個線程的生命周期設定較長等待時間，就可能由于雖然線程處于空閑狀態但其他用戶請求無法使用，從而造成資源浪費，引起系統性能下降；如果線程生命周期設定較短等待時間，就可能會發生用戶的新請求需要分配新的線程，增加了線程切換的開銷，也會導致系統性能的下降。c）如果長周期的請求消耗了所有線程，就不能滿足新的需要更少資源、優先級更高的請求。

當前Web服務器面臨的一個重要問題就是QoS控制問題。決定Web服務器的QoS主要有兩個因素，即網絡傳輸質量和Web服務器的處理能力。對網絡傳輸QoS的研究近年來比較活躍，包括提供點對點QoS保證的集合服務體系結構和提供不同的可替代的服務水平的差異服務體系結構[8]。然而網絡層的QoS不能提供用戶追求的性能，如果Web服務器不支持差異服務，當Web服務器過載時一個擁有點對點QoS保證的請求的數據流仍可能被拒絕。最近支持QoS的Web服務器研究集中在Web服務器優先級任務處理上，這種Web服務器的主要屬性包括將客戶請求分為有不同服務需求的組，根據任務組分配資源、基于優先級的調度和任務分配策略等。目前Web服務器實現QoS的研究多采用嚴格優先級調度算法[9~11]。在這種算法中，不同類別請求有不同的嚴格確定的優先級， Web服務器總是執行已接收請求中優先級最高的請求。 文獻[12]也提出了一種稱為PACERS的調度算法，通過預測HTTP請求的服務延遲時間來進行訪問控制。嚴格優先級調度算法有以下缺點：a）低優先級類別請求可能會發生饑餓現象；b）不同類別請求的性能差距依賴于系統負載。例如，客戶A的請求處理速度為Ra，客戶B的請求處理速度為Rb，在嚴格優先級調度中，如果不考慮系統當時的負載，保持兩個類別請求的性能比Ra/Rb不變是非常困難的。

5 結束語

本文從解決日益復雜的Web服務器遇到的問題入手，提出了一種新型的Web服務器體系結構。采用事件驅動和訪問控制的Web服務器體系結構，在動態的環境下能充分利用系統資源、不同類別的QoS差異保持穩定、系統負載過載時能很好地進行訪問控制。通過測試對比顯示，本文設計的系統具有高效的并發事務處理能力、良好的可用性、可行性等優點。今后將會完善Web服務器的體系結構，擴展其動態數據處理能力，并進一步研究異步I/O方式的Java實現。

參考文獻:

[1]BHATTI N， FRIEDRICH R. Web server support for tiered services[J]. IEEE Network， 1999， 13(5):64-71.

[2]MOGUL J C. Network behavior of a busy Web server and its clients， WRL 95/5[R]. Palo Alto: DEC Western Research Laboratory， 1995.

[3]KLEINROCK L. Queueing systems， vol2:computer applications[M]. New York:Wiley， 1976.

[4]MOSBERGER D， JIN Tai. A tool for measuring Web server performance[EB/OL]. (1998). http://www.hpl.hp.com/personal /David _Mosberger/httperf.html.

[5]Zeus Technology. Comparing high performance Web servers[EB/OL](2002). http://www.zeus.com/documents/en/zw/zws_comparison.pdf

[6]PAI V S，RUSCHEL P， ZWAENPOEL W. Flash: an efficient and portable Web server[C]//Proc of USENIX Annual Technical Confe-rence. 1999:199-212.

[7]WELSH M. An architechure for highly concurrent[D]. Berkeley:University of California， 2002.

[8]Differentiated services (diffserv)[EB/OL].(2003). http://www.ietf.org/html.charters/OLD/diffserv-charter.html.

[9]ABDELZAHER T F， SHIN K G. QoS provisioning with q contracts in Web and multimedia servers[C]//Proc of the 20th IEEE Real-time Systems Symposium. Washington DC:IEEE Computer Society， 1999:44.

[10]LI B， NAHRSTEDT K. A control-based middleware framework for quality of service adaptations[J]. IEEE Journal of Selected Areas in Communication， Special Issue on Service Enabling Platforms， 1999，17(9):1632-1650.

[11]LEE S， LUI J， YAU D. Admission control and dynamic adaptation for a proportional-delay diffserv-enabled Web server[J]. ACM SIGMETRICS Performance Evaluation Review， 2002:30(1):172-182.

[12]CHEN Xiang-ping， MOHAPATRA P， CHEN Hua-min. An admission control scheme for predictable server response time for Web accesses[C]//Proc of the 10th WWW Conference. New York:ACM Press， 2001:545-554.