天天看點

nginx并發模型與traffic_server并發模型簡單比較

ginx并發模型:

nginx

的程序模型采用的是prefork方式,預先配置設定的worker子程序數量由配置檔案指定,預設為1,不超過1024。master主程序建立監聽套接口,fork子程序以後,由worker程序監聽客戶連接配接,每個worker子程序獨自嘗試accept已連接配接套接口,accept是否上鎖可以配置,預設會上鎖,如果作業系統支援原子整型,才會使用共享記憶體實作原子上鎖,否則使用檔案上鎖。不使用鎖的時候,當多個程序同時accept,當一個連接配接來的時候多個程序同時被喚起,會導緻驚群問題。使用鎖的時候,隻會有一個worker阻塞在accept上,其他的程序則會不能擷取鎖而阻塞,這樣就解決了驚群的問題。master程序通過socketpair向worker子程序發送指令,終端也可以向master發送各種指令,子程序通過發送信号給master程序的方式與其通信,worker之間通過unix套接口通信。

模型如下圖:

nginx并發模型與traffic_server并發模型簡單比較

Traffic server并發模型:多線程異步事件處理

traffic_cop和traffic_manager作為管理程序,工作程序為traffic_server,traffic_server負責listen和accept,為提高性能,traffic_server使用了異步I/O和多線程技術。Traffic

Server并不是為每個連接配接都建立一個線程,而是事先建立一組數量可配置的工作線程,每一個工作線程上都運作着獨立的異步事件處理程式。traffic_server建立若幹組Thread,并将Event按類型排程到相應的Thread的Event隊列上,Thread通過執行Event對應的Continuation中的回調函數,來完成狀态的遷移。從初始态到終止态的遷移代表了整個事件的執行過程,而Thread是永不退出的,等待着下一個事件的到來。模型如下圖:

nginx并發模型與traffic_server并發模型簡單比較

兩種伺服器都涉及到網絡I/O操作,nginx使用的是linux的epoll模型,traffic

server使用異步I/O,由于對于I/O不熟悉,這份就不做深入對比。都使用預配置設定機制,nginx預配置設定worker程序,traffic

server 預配置設定工作線程。

對比分析:

1.并發度:

nginx使用的多程序并發模型,采用多程序監聽新連接配接,為此它不需要分發操作,但是引入鎖來保持同步,舍去了分發的開銷,但是引入了鎖的開銷。實際中鎖的開銷比較小,如果系統支援原子整形,那麼鎖的開銷會進一步降低;通過worker程序自己主動去accept,這也會讓各個worker程序的負載量比較均衡,這依賴于系統核心對程序的公平的排程。worker程序也可以配置成使用線程進行事件處理工作,但模型上還是屬于多程序并發,因為線程需要從程序這裡取到事件。這種設計有一個缺陷,worker程序的數量不能太多,nginx設計的worker程序數量的最大值為1024,太多的worker程序會導緻程序之間競争資源頻繁,使系統運作緩慢。可見nginx被設計成輕量級的web伺服器,但是作為輕量級的web伺服器,它有着非常好的性能表現,有報告表明能支援高達

50,000個并發連接配接數。nginx不愧是輕量級web反向代理伺服器的首選。

而traffic

server使用多線程異步事件處理模型:将多線程技術與異步事件處理技術結合在一起來提高并發和性能。多線程程式可以充分利用現代處理器多核的處理能力,使一個程序的多個任務可以并行執行,提高程式執行的效率。這種多線程的設計也讓traffic

server的性能與處理器的性能一直成正比,不會像nginx收到worker程序數目的限制。它不是作為輕量級的web伺服器而設計的,它支援叢集,Apache

Traffic Server v.3.0.0基準測試的結果是每秒鐘可以處理200,000多個請求,可見traffic

server不愧是高性能的web伺服器,個人認為這款伺服器将會是以後的發展趨勢。

2.響應時間

nginx采用的是worker程序獨立accept而直接進行處理的方式處理客戶請求,是以nginx的響應速度應該是很快的,個人覺得應該比traffic server伺服器要更快。

traffic server是server程序接受請求,然後分發到請求隊列中,再由處理線程進行處理,是以理論上響應時間沒有nginx快。

網絡上的測試文檔有表明在請求靜态網頁的時候,響應速度時間約為5:7,(網上資料,本人沒有測試),和分析相符。

3.穩定性

nginx由于是很多能夠獨立工作的worker程序在工作,當其中的某個或一些worker程序異常時不影響系統的正常工作。master程序在初始化worker程序以後就在循環體中檢測信号,然後處理信号,由于master程序一直會比較穩定,當它發現worker程序異常時,又會去重新開機該worker程序,而且還會檢查其他worker程序。可見nginx的這種設計容錯性是很高的。

traffic

server中由于server是工作程序,而且隻有一個,是以系統要保障它的正常運作。為此系統添加了traffic_cop程序與traffic_manager程序來管理server程序,給server程序加上了雙重的保障,當server異常時,traffic_manager程序會及時的重新開機它,而且在重新開機的過程中還會繼續利用traffic_manager程序來接受客戶請求,這是個不錯的設計。當traffic_manager程序和sever程序同時異常結束的時候,traffic_cop又會重新開機它們,是以系統的穩定性也是很高的。

由于traffic server重新開機的過程中無法繼續服務,是以穩定性上nginx要勝過traffic server。

4.峰值響應

web伺服器都很關心當一小段時間内有大量的連接配接請求的時候伺服器的響情況的。

nginx由于是多個worker程序工作,大量請求來的時候各個worker的負載會比較均勻分布,當峰值過高時,會導緻worker程序排程延遲,也就會阻塞客戶請求,說明伺服器的處理能力會阻塞客戶請求,它們之間會存在一個限制關系。另外而Nginx采取了分階段資源配置設定技術,由cache

manager程序和cache loader

程序處理,這種設計也會使得nginx在遇到峰值請求的時候不輕易的将記憶體耗盡,不容易造成系統在過載請求下異常結束。

server使用server程序接收到大量的使用者請求後會發送到請求隊列,然後線程在處理的時候會造成資料量過大,容易記憶體耗盡,出現異常導緻server程序也退出,雖然會很快的重新開機該程序(官方文檔說重新開機隻需要幾秒鐘),而且重新開機的過程中還會由manager程序繼續接受請求,但是系統卻在這段時間内無法處理請求,但是nginx不會停止處理請求。(traffic

server沒有叢集的情況下)

分析說明在短時間爆發性通路的時候nginx的響應能力要優于traffic

server。這裡說的過載請求量是針對它們各自不同的請求量,比如nginx處理能力為50000連接配接,那麼它的峰值就是50000,它們的反應僅是針對各自的峰值請求。但是traffic

server支援叢集,這将會很大程度的的提高其峰值響應能力。

5.安全性

nginx對于安全性做的工作不多,惡意連接配接攻擊可能會導緻worker程序耗盡系統資源而停止響應,雖然master程序會檢測并嘗試重新開機,如果master程序也是去響應,那麼系統就需要重新開機。但是nginx采用分階段資源配置設定技術,系統很難會耗盡全部的資源而是去響應,是以一般的dos攻擊對于nginx是沒什麼效果的。總體來說安全性一般。

server在安全性方面做了很多工作,系統會周期性調用heartbeat_manager函數和heartbeat_server函數來檢查manager程序和server程序的健康狀況,發現不正常時則會立即重新開機響應的異常程序。而且一旦server程序異常結束,也會很快被重新開機。是以當收到攻擊的時候,traffic

server會比較及時的作出反應,系統安全性比較高。

總結:個人認為nginx是多程序并發模型的典範,而traffic

server是多線程異步事件處理模型的典範,各有其優缺點。nginx是一款優秀的輕量級web伺服器,适合處理請求不多的情況;traffic

server則是一款高性能web伺服器,還支援叢集,更适合處理大量請求連接配接的情況。