多維Web服務(wù)網(wǎng)關(guān)的高并發(fā)問題研究*

尼四凱 ，王 勇 ，鐘明旸

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

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

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

針對多維網(wǎng)關(guān)所出現(xiàn)的各種問題，本文設(shè)計了一種改進的線程池解決方案。該方案對經(jīng)典的線程池設(shè)計模式進行改進后，首次應(yīng)用在多維網(wǎng)關(guān)上，并作為多維網(wǎng)關(guān)處理消息轉(zhuǎn)發(fā)的一種核心技術(shù)，有效地解決了多維Web服務(wù)網(wǎng)關(guān)在高并發(fā)情況下的擁塞問題。

1 傳統(tǒng)的多線程高并發(fā)服務(wù)器的原理及實現(xiàn)技術(shù)

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

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

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

2.1 傳統(tǒng)線程池應(yīng)用與多維Web服務(wù)網(wǎng)關(guān)的缺陷

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

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

(1)優(yōu)化工作線程數(shù)目。根據(jù)統(tǒng)計學(xué)的原理來統(tǒng)計客戶的請求數(shù)目，比如高峰時段平均1 s內(nèi)有多少任務(wù)要求處理，并根據(jù)系統(tǒng)的承受能力及客戶的忍受能力來平衡估計一個合理的線程池尺寸。

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

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

2.2 改進后的線程池設(shè)計流程

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

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

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

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

Tl是從數(shù)據(jù)獲取到失效的生存時間，每個生存時間與請求的優(yōu)先級有關(guān)。每個服務(wù)請求都設(shè)置一個用戶時間容忍度ρ。網(wǎng)絡(luò)請求超時極值為T(T的值為50 s)。則Tl的取值為：

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

其中，n為在30 min內(nèi)的請求總數(shù)。

3 對比測試及結(jié)果分析

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

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

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

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

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

根據(jù)第一次測試結(jié)果選取線程池大小固定為16個線程，改進后的線程池算法的瞬時同類請求合并模塊時間參數(shù)設(shè)置為0.5 s。改變?nèi)蝿?wù)數(shù)對3種服務(wù)器進行再次測試。

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

圖4 3種算法對比圖

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

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

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

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

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

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