多維Web服務網關的高并發問題研究*

尼四凱 ，王 勇 ，鐘明旸

(1.桂林電子科技大學 電子工程與自動化學院，廣西 桂林541004；2.桂林電子科技大學 計算機科學與工程學院，廣西 桂林541004；3.桂林電子科技大學 信息與通信學院，廣西 桂林541004)

在信息化、數字化的今天，計算機網絡已經完全融入了人類的生活、生產當中[1]。人與人之間可以通過網絡進行信息傳遞和資源共享，人與物、物與物之間也可以通過網絡進行交流。多維Web服務網關就是在這種背景下提出的。多維Web服務網關是融合了當前互聯網技術、嵌入式技術、無線傳感網技術和Web Service技術的一種可以為互聯網用戶提供所監測環境的實時數據并可以對其進行控制的網關。該網關最大的特點是使用了Web Service技術，這種技術給互聯網用戶提供了一種平臺獨立、松耦合、自包含、基于可編程的Web應用程序，可以使用開放的XML標準來描述、發布、發現、協調和配置這些應用程序。多維Web服務網關的關鍵核心技術是處理來自互聯網用戶的請求，并從底層的傳感網中讀取相應的數據并反饋給用戶。

由于多維服務網關提供的是開放的可供查詢的服務，因此很可能遭遇到瞬時大量用戶訪問的情況(高并發情況)。針對該情況，傳統的基于多線程和Select機制的并發服務器由于受到系統硬件資源的限制，已經不能滿足高實時性、高可靠性的要求了。另外由于多維網關有WiFi、千兆以太網端口、3G、ZigBee等多種信道，各種信道的傳輸速率不同，這也會增加服務器出現擁塞狀況。

針對多維網關所出現的各種問題，本文設計了一種改進的線程池解決方案。該方案對經典的線程池設計模式進行改進后，首次應用在多維網關上，并作為多維網關處理消息轉發的一種核心技術，有效地解決了多維Web服務網關在高并發情況下的擁塞問題。

1 傳統的多線程高并發服務器的原理及實現技術

早期的服務器采用多進程來解決高并發問題，但是進程的創建開銷很大，對服務器性能要求比較高，相比較而言線程的資源開銷比進程小得多，而且子線程的創建速度快，同一進程內的子線程之間進行切換花費也小，子線程之間的通信也易實現，所以多線程技術很快取代了多進程用于高并發服務器的設計上[2]。

多線程技術雖然比多進程在一定程度上改善了服務器性能，但卻存在著致命的缺陷。首先大量用戶請求所帶來的線程不停地創建和銷毀，將會消耗CPU大量的處理時間，也會造成響應的時延，從而使得網絡擁塞[3-4]。線程池技術的利用大大改善了服務器在高并發情況下的性能下降問題，該技術通過在程序開始時創建一批線程來處理到來的用戶請求，用戶請求多于線程池線程數目時可以把請求任務暫時放在任務隊列中，等線程池中有了空閑的線程再從任務隊列中取出任務交給空閑線程去處理；當用戶請求少于線程池線程數目時，空閑線程掛起等待[5]。

2 改進的線程池算法的提出

2.1 傳統線程池應用與多維Web服務網關的缺陷

簡單線程池存在的問題是：如果有大量的客戶要求服務器為其服務，但由于線程池的工作線程是有限的，服務器只能為部分客戶服務，其他客戶提交的任務只能在任務隊列中等待處理。這種狀況直接增加了服務網關的響應時間，所以調整優化線程池尺寸是高級線程池要解決的一個問題。另外，由于多維Web服務網關要與底層的無線傳感網通信來獲取實時數據，假設服務器解析用戶請求的時間為T1，服務器從傳感網中相應的節點獲取數據的時間為T2，請求和響應在互聯網中的傳輸時間為T3，完成單次用戶請求任務的總時間為T，則有：

所以，對于多維網關來說，降低T2和T3的時間也是比較有效的策略。綜上，本文對簡單的線程池提出了如下兩點改進：

(1)優化工作線程數目。根據統計學的原理來統計客戶的請求數目，比如高峰時段平均1 s內有多少任務要求處理，并根據系統的承受能力及客戶的忍受能力來平衡估計一個合理的線程池尺寸。

(2)給線程池添加瞬時同類請求合并模塊。由于網絡用戶對多維網關的請求大部分為數據請求，控制請求比較少，并且控制請求在時間上不太集中，因此將短時間T1內的大量同類數據請求合并為一個請求，而對于控制請求則不予合并直接通過該模塊。根據式(1)～式(3)可知，減少對底層傳感網的訪問能有效地降低整個網絡時延。假設：網關收到的請求中數據請求占90%，控制請求和服務描述請求各占5%，網關對底層的無線傳感網訪問一次耗時為Tw；網關提供了10個服務，其中提供數據的服務和提供控制的服務各占一半；網關1 s內收到了N個服務請求，那么使用簡單線程池的服務網關完成N個請求要花費在底層傳感網訪問的時間為Tb，使用添加了合并模塊的線程池服務網關所花費時間為Ta，其中 Tl設置為 1 s，則有：

當 N=100 時 ，Tb=95 Tw，Ta=10 Tw； 當 N=500 時 ，Tb=475 Tw，Ta=30 Tw。所以當訪問量越多時，改進后的算法優勢越明顯。

2.2 改進后的線程池設計流程

如圖1所示，改進后的算法分為兩大部分，添加了瞬時同類請求合并模塊，線程池中每個工作線程中的任務都要經過該模塊的過濾才可以訪問底層的傳感網。

圖1 改進后的線程池算法流程圖

圖2給出了瞬時同類請求合并模塊的詳細流程圖，算法的基本思想是對實時性要求比較高的控制類請求進行直接轉發，對于數據請求在允許的時間內對其進行合并。也就是在瞬時Tl內對首個數據請求直接轉發給傳感網絡，讀取數據后把結果返回給客戶端，同時在服務器數據庫中插入該條數據和請求類型，并設置一個時間為Tl的定時器，定時器到時間后即刪除該條數據。新到的同類請求不再訪問傳感網絡，而是直接檢查數據庫是否有同類請求，有則直接從數據庫讀取數據并返回給客戶端；否則重復以上步驟。該設計使用了SQLite數據庫，由于SQLite是一個使用C代碼編寫的小型數據庫，大小不足270 KB，讀寫速度非?？欤貏e適合嵌入式設備。

圖2 瞬時同類請求合并模塊算法流程圖

Tl是從數據獲取到失效的生存時間，每個生存時間與請求的優先級有關。每個服務請求都設置一個用戶時間容忍度ρ。網絡請求超時極值為T(T的值為50 s)。則Tl的取值為：

容忍度ρ的取值范圍為0～1，實時性要求越高的服務其ρ的取值越小，控制類的ρ取值一律為0。當某個請求量很大時，其ρ的取值也會增大。ρ的計算公式為：

其中，n為在30 min內的請求總數。

3 對比測試及結果分析

本文使用C語言在Linux系統下實現了改進后線程池算法，并對其性能進行了測試。下面是使用jmeter壓力測試工具對改進前后的線程池算法服務器和多線程服務器進行的對比測試，測試環境均為Linux(2.6內核)，Inter Pentium Dual E2180處理器，512 MB內存。

(1)選擇最優線程池尺寸測試

改變線程池的大小，任務數設置為2 000，對多線程的服務器進行測試。

如圖3所示，線程池容量在32之前一直比較穩定，并維持在非常好的效果，明顯優于多線程服務算法。容量在32之后線程池算法服務器性能開始下降，特別是在128之后，性能下降明顯，在300之后性能差于多線程服務器。線程池尺寸可以選擇8～32個線程。

(2)3種算法對比測試結果

根據第一次測試結果選取線程池大小固定為16個線程，改進后的線程池算法的瞬時同類請求合并模塊時間參數設置為0.5 s。改變任務數對3種服務器進行再次測試。

圖3 多線程和線程池對比圖

圖4 3種算法對比圖

如圖4所示，線程池算法表現比較穩定。在任務數為64個之前，3種算法服務器的性能差別不明顯；在任務數為128之后性能開始出現差異，特別是任務數在256之后，改進后的線程池算法明顯優于多線程算法服務器；在任務數達到512個之后，改進后的線程池算法開始體現出明顯的優勢。

[1]黃冬泉.高并發事件驅動服務器研究[J].計算機工程與科學，2007，29(1)：138-141.

[2]許永達.基于線程池的高并發訪問考試系統設計[J].計算機與現代化，2013，4(3)：232-234.

[3]孫旭東，韓江洪，劉征宇，等.基于分段的線程池尺寸自適應調整算法[J].計算機工程，2013，37(2)：43-44.

[4]楊開杰，劉秋菊，徐汀榮.線程池的多線程并發控制技術研究[J].計算機應用與軟件，2010，27(1)：168-170.

[5]唐富強，于鴻洋，張萍.Linux下通用線程池的改進與實現[J].計算機工程與應用，2012，48（28）：77-83.