《電子技術應用》
您所在的位置:首頁 > 通信與網絡 > 設計應用 > 多維Web服務網關的高并發(fā)問題研究
多維Web服務網關的高并發(fā)問題研究
2014年微型機與應用第14期
尼四凱1,王 勇2,鐘明旸3
桂林電子科技大學
摘要: 為了解決多維服務網關因高并發(fā)情況而導致的網絡擁塞、服務器性能降低問題,提出了一種改進的線程池服務器設計方法。首先根據(jù)經驗值創(chuàng)建一個尺寸最優(yōu)的線程池,并結合SQLite數(shù)據(jù)庫為線程池添加一個瞬時同類服務請求合并模塊。該模塊對請求連接進行分類,劃分優(yōu)先級,然后根據(jù)不同的請求優(yōu)先級把與其優(yōu)先級對應的Tl秒內的同類請求合并為1個請求,以此來降低整個服務過程的時延,提高請求響應速度。實驗表明,該設計能夠有效地降低高并發(fā)情況下的擁塞現(xiàn)象,并降低網絡時延。
Abstract:
Key words :

  摘  要: 為了解決多維服務網關因高并發(fā)情況而導致的網絡擁塞、服務器性能降低問題,提出了一種改進的線程池服務器設計方法。首先根據(jù)經驗值創(chuàng)建一個尺寸最優(yōu)的線程池,并結合SQLite數(shù)據(jù)庫為線程池添加一個瞬時同類服務請求合并模塊。該模塊對請求連接進行分類,劃分優(yōu)先級,然后根據(jù)不同的請求優(yōu)先級把與其優(yōu)先級對應的Tl秒內的同類請求合并為1個請求,以此來降低整個服務過程的時延,提高請求響應速度。實驗表明,該設計能夠有效地降低高并發(fā)情況下的擁塞現(xiàn)象,并降低網絡時延。

  關鍵詞: 多維網關多任務處理;高并發(fā);線程池

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

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

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

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

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

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

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

  2.1 傳統(tǒng)線程池應用與多維Web服務網關的缺陷

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

  T=T1+T2+T3(1)

  T2>>T1(2)

  T3>>T1(3)

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

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

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

  Tb=N×95%×Tw(4)

  Ta=(N×5%+10×50%)×Tw(5)

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

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

001.jpg

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

002.jpg

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

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

  Tl=T×ρ(6)

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

  0VD~_D4IP@R1SMPQH]V)UDO.png

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

  3 對比測試及結果分析

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

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

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

003.jpg

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

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

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

004.jpg

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

  參考文獻

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

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

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

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

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


此內容為AET網站原創(chuàng),未經授權禁止轉載。