陳 濤，任海蘭

（武漢郵電科學(xué)研究院 湖北 武漢 430074）

Web服務(wù)器常常需要處理多個并發(fā)請求，針對每一個請求，Web服務(wù)器會有相應(yīng)的并發(fā)程序來執(zhí)行相關(guān)操作。

這一過程中，使用進(jìn)程是構(gòu)造并發(fā)程序最簡單的方法：為了實現(xiàn)進(jìn)程間的信息交互，它們必須使用顯式的進(jìn)程間通信（（IPC）機(jī)制，由于進(jìn)程控制和IPC的開銷很高導(dǎo)致基于進(jìn)程的設(shè)計運(yùn)行速度往往比較慢[2-4]。

為解決進(jìn)程間信息共享而造成的高開銷問題，本文采用多線程池的并發(fā)設(shè)計，利用信號量訪問共享變量，使用生產(chǎn)者一消費(fèi)者模型降低線程開銷，從而提高系統(tǒng)訪問速度和資源利用率。

1 基于多進(jìn)程Web服務(wù)器的不足

目前主流boa服務(wù)器主要基于多進(jìn)程來構(gòu)造并發(fā)程序。首先由父進(jìn)程去接受客戶端的連接請求，然后創(chuàng)建一個新的子進(jìn)程去為每一個客戶端提供服務(wù)。這種父子進(jìn)程會共享文件表，但是不共享用戶地址空間。基于這種特性，這類進(jìn)程中不會存在一個進(jìn)程覆蓋另一個進(jìn)程的虛擬存儲器，但是這也使得進(jìn)程共享狀態(tài)信息變得更加困難，因而基于多進(jìn)程Web服務(wù)器引入了IPC機(jī)制。

在面對大量并發(fā)處理請求時，由于進(jìn)程機(jī)制和IPC機(jī)制開銷大，會使得服務(wù)器延時效果明顯。

2 改進(jìn)服務(wù)器的設(shè)計要素

2.1 基于線程池的并發(fā)設(shè)計

線程是程序執(zhí)行流的最小單元，線程由內(nèi)核自動調(diào)度。一個進(jìn)程里可以同時運(yùn)行多個線程，每個線程都有自己的線程上下文，包括一個唯一的棧、棧指針、條件碼、程序計數(shù)器、整數(shù)線程ID、通用目的寄存器，運(yùn)行在同一個進(jìn)程里的所有線程共享該進(jìn)程的整個虛擬地址空間。

同時，線程執(zhí)行又區(qū)別于進(jìn)程執(zhí)行，在于:1）較于進(jìn)程環(huán)境，一個線程環(huán)境擁有的系統(tǒng)資源極少；2）線程不構(gòu)成父子層次關(guān)系。

在線程池技術(shù)中，我們在任務(wù)還沒有到來之前，創(chuàng)建一定默認(rèn)數(shù)量的線程。這些線程均處于睡眠狀態(tài)，不消耗CPU，只占用較少的內(nèi)存空間。當(dāng)輪詢到有請求到來后，線程池將會分配給這次請求一個空閑的線程，進(jìn)行執(zhí)行。

當(dāng)預(yù)先創(chuàng)建的線程都已處于運(yùn)行狀態(tài)，即并發(fā)請求數(shù)量多于線程池中最少空閑線程數(shù)時，線程池將會自由創(chuàng)建一定數(shù)量的新線程，用于處理更多的并發(fā)請求。當(dāng)系統(tǒng)比較閑的時候，線程池就會移除一部分已經(jīng)停用的線程，以減少系統(tǒng)負(fù)荷。

線程池技術(shù)由于具有節(jié)省系統(tǒng)開銷，信息共享容易，完成時間短的優(yōu)點非常適合處理大數(shù)量的并發(fā)請求。

2.2 基于信號量機(jī)制的資源共享

信號量模型只支持P，V兩種操作，且均為原子操作，要么都不執(zhí)行，要么全部執(zhí)行[5-6]。

1）P（s）:如果 S 為非零，那么 P 操作就將 S 的值減 1，然后返回。如果S為零，那么當(dāng)前進(jìn)程（線程）將會被阻塞，直至S值不為0；當(dāng)S值不為0，被阻塞的進(jìn)程會重啟。重啟之后，S的值減1。

2）V（s）:對S進(jìn)行操作，就是將 S的值加 1。 為實現(xiàn)內(nèi)核同一時刻對共享變量的互斥訪問，將信號量（初始值為1）與共享變量聯(lián)系起來，用P和V操作將相應(yīng)的臨界區(qū)保護(hù)起來，從而使得在任何時間點上，信號量操作確保對臨界區(qū)的互斥訪問。

調(diào)度對共享資源的訪問是信號量的另一個重要作用，在某一時刻，程序中某個條件一旦為真，一個線程會通過信號量來告知其他線程允許訪問。

2.3 生產(chǎn)者一消費(fèi)者模型

圖1所示的生產(chǎn)者—消費(fèi)者模型是一個經(jīng)典的信號量調(diào)度同步示例。生產(chǎn)者和消費(fèi)者線程共享一個有限單元的緩存區(qū)。

圖1 生產(chǎn)者一消費(fèi)者模型Fig.1 Producer-consumer model

生產(chǎn)者線程不斷地生產(chǎn)新的項目并把它們插入到緩存區(qū)中；消費(fèi)者線程則不斷地從緩存區(qū)中取出這些項目，然后消費(fèi)它們。模型中允許有數(shù)量不同的生產(chǎn)者和消費(fèi)者。

在本次設(shè)計中，生產(chǎn)者線程，消費(fèi)者線程均來自于線程池。主程序輪詢到請求到來后，線程池會給請求分配一個空閑的線程，進(jìn)行相關(guān)任務(wù)的執(zhí)行。

由于插入和取出兩種操作涉及到對緩存區(qū)共享變量的更新，所以需要保證它們的互斥訪問。除此之外，還需要考慮調(diào)度對緩存區(qū)的訪問，例如，當(dāng)緩存區(qū)為空的時候，消費(fèi)者將被阻塞，直到不為空的時候被喚醒；同理，當(dāng)緩存區(qū)滿的情況下，生產(chǎn)者應(yīng)該被阻塞，等待有空的位置出現(xiàn)。

3 多線程池并發(fā)的Web服務(wù)器設(shè)計

3.1 設(shè)計模型

在Web服務(wù)程序中，通常將收到的客戶請求分為如下4個部分來進(jìn)行處理：

1）監(jiān)聽服務(wù)端口，與客戶端建立連接；

2）解析URL與報頭；

3）靜態(tài)/動態(tài)請求處理；

4）消息的應(yīng)答機(jī)制。

本文基于多線程池并發(fā)Web服務(wù)器設(shè)計模型如圖2所示。

圖2 多線程池并發(fā)服務(wù)器模型Fig.2 Concurrent multi-threaded server model pool

圖2 中每一個數(shù)據(jù)隊列均有對應(yīng)的線程池對其進(jìn)行輪詢。在每個線程池中，都有一定數(shù)量的處于睡眠狀態(tài)的線程。主程序在監(jiān)聽到請求后，將請求消息放入請求解析數(shù)據(jù)隊列。線程池輪詢到有新請求，會給每個消息請求分配一個空閑線程。當(dāng)有多個并發(fā)請求到來時，將會出現(xiàn)報文解析線程組。用戶請求信息完成報文解析處理后，將進(jìn)入事物處理請求隊列。請求在事物處理隊列和消息回復(fù)隊列中的處理機(jī)制一致。

這樣一來，每種任務(wù)線程最多只需關(guān)心自己的處理程序，與和自己相關(guān)的幾個消息隊列即可。這種方式使服務(wù)模塊化，易于管理和維護(hù)。流水線的工作方式使服務(wù)器的多任務(wù)處理性能得到進(jìn)一步優(yōu)化。

3.2 Web服務(wù)器主要處理流程

根據(jù)網(wǎng)絡(luò)應(yīng)用程序的開發(fā)模型和HTTP協(xié)議，Web服務(wù)器設(shè)計實現(xiàn)的主要操作流程及功能如下：

1）主函數(shù)處理流程：緩沖I/O初始化-＞打開監(jiān)聽端口-＞建立線程組-＞監(jiān)聽請求連接-＞將連接放入線程組-＞從連接組中取出連接-＞執(zhí)行指定服務(wù)。

2）服務(wù)器響應(yīng)請求流程：讀取請求-＞獲取請求方法、URL、和版本-＞判斷請求方法-＞解析URL-＞判斷訪問權(quán)限-＞放入事務(wù)請求處理隊列。

3）解析 URL流程：根據(jù) CGI判斷靜態(tài)/動態(tài)標(biāo)服務(wù)-＞拷貝URL到FILENAME中-＞添加默認(rèn)文件home.html-＞返回靜態(tài)/動態(tài)標(biāo)志。

4）為客戶端提供靜態(tài)服務(wù)流程：打開指定文件-＞拷貝到虛擬內(nèi)存-＞拷貝虛擬內(nèi)存至指定賬戶-＞關(guān)閉描述符、釋放虛擬內(nèi)存。

5）為客戶端提供動態(tài)服務(wù)流程：構(gòu)造線程來執(zhí)行CGI程序-＞通過調(diào)用不同的參數(shù)，來產(chǎn)生細(xì)節(jié)不同的動態(tài)文檔-＞等待線程執(zhí)行結(jié)束，回收資源。

4 改進(jìn)Web服務(wù)器性能測試

依據(jù)上述設(shè)計理念，Web服務(wù)器在Linux系統(tǒng)下采用C語言編寫，用gcc編譯實現(xiàn)。

圖3給出了訪問靜態(tài)頁test.html的效果示意圖，圖4給出了訪問動態(tài)頁cgi-bin/add的效果示意圖。測試證明該Web服務(wù)器能實現(xiàn)服務(wù)器的基本功能，即在服務(wù)器端接收到HTTP請求后，可以予以響應(yīng)。

圖3 靜態(tài)頁面Fig.3 Static pages

圖4 動態(tài)頁面Fig.4 Dynamic pages

Apache中有個名為ab的程序，可以對Apache其它類型的服務(wù)器進(jìn)行網(wǎng)站訪問壓力測試。本文使用該軟件來進(jìn)行壓力測試，兩次測試中，均向目標(biāo)Web服務(wù)器累計發(fā)出1 000次請求，每次100個請求并發(fā)（模擬 100人同時訪問），圖5為普通嵌入式Boa服務(wù)器測試結(jié)果截圖，圖6為改進(jìn)后Web服務(wù)器測試結(jié)果截圖。

圖5 普通web服務(wù)器測試結(jié)果Fig.5 Results of ordinary web server test

圖6 改進(jìn)后Web服務(wù)器測試結(jié)果Fig.6 Results of improved web server test

這兩份性能測試單有兩個重要測試指標(biāo)：1）每秒鐘平均處理的請求數(shù)；2）每個線程下的一組請求（100個）平均消耗時間。改進(jìn)服務(wù)器前后數(shù)據(jù)分別為:7.35/9.19（改進(jìn)后），13 607.549 ms/10 884.814 ms（改進(jìn)后）。

通過數(shù)據(jù)可以看出改進(jìn)后的Web服務(wù)器能有效降低系統(tǒng)開銷，大幅度提高Web服務(wù)器的系統(tǒng)資源利用率和服務(wù)效率。

5 結(jié)束語

基于進(jìn)程或單純基于線程服務(wù)器普遍會存在著利用率不高、資源消耗大等問題。本文設(shè)計的基于多線程池并發(fā)Web服務(wù)器，利用生產(chǎn)者一消費(fèi)者模型和多線程池高效率實現(xiàn)了資源調(diào)度及共享。設(shè)計實現(xiàn)的改進(jìn)Web服務(wù)器能實現(xiàn)Web服務(wù)器的基本功能，能接受一定規(guī)模的并發(fā)客戶請求并予以響應(yīng)，具有較高的服務(wù)效率。后續(xù)還有一些工作需要完善，如進(jìn)一步完善用戶的動態(tài)請求處理，加強(qiáng)對請求頭信息的分析等。

[1]Randal E Bryant，David O'Hallaron.Computer systems:a programmer's perspec；tive[M].New Jersey:Prentioe Hall Publisher.2003.

[2]張根寶，胡杰.Linux集群環(huán)境下監(jiān)控Web服務(wù)器的Shell腳本設(shè)計[J].化工自動化及儀表，2010，37（10）:99-101.ZHANG Gen-bao，HU Jie.Shell script design of monitoring web server under linux cluster environment[J].Control and Instruments in Chemical Industry，2010，37（10）:99-101.

[3]張估，曹奇英.Web服務(wù)器負(fù)載壓力模型及其優(yōu)化原則[J].計算機(jī)應(yīng)用軟件與軟件，2010，27（12）:139-141.ZHANG Gu，CAO Qi-ying.Load pressure model and optimization principles of web server[J].Computer Applications and Software，2010，27（12）:139-141.

[4]胡中棟，曾志勇.基于多路徑的DSR路由協(xié)議改進(jìn)[J].江西理工大學(xué)學(xué)報，2011，32（3）:45-48.HU Zhong-dong，ZENG Zhi-yong.Improved DSR-routing protocol based on multipath[J].The Jiangxi University of Science and Technology Journal，2011，32（3）:45-48.

[5]Richard Stevens W，Bill Fenner.Unix network programming volume 1:the Sockets networking API，third edition[M].New Jersey:Prentice Hall Publisher，2003.

[6]Tanenbaum A.Modern operating systems，third edition[M].New Jersey:Prentice Hall Pnhlisher，2007.