NGINX 架構 - 《事件驅動處理函數庫》
2022/07/08閱讀時間約 5 分鐘
承上篇【NGINX 架構 - 事件驅動架構】後續，這篇開始記錄函數庫的相關筆記
事件驅動處理函數庫：
函數庫的細節，就沒打算太過深入，我們只要知道模型的運作方式、優缺點及如何使用就足夠了。
1. select模型：
此模型會先建立分別為Read、Write、Exception的三個「事件描述符集合」，然後透過輪詢的方式，去詢問三個集合，是否有事件發生，如果有就處理。
【優點：不管是Linux還是Windows，市面上幾乎的作業系統都支持此模型】 【缺點：描述符集合最多只支援1024(32位元)、2048(64位元)】
【缺點：輪詢的方式效率較低，不管集合是否為空，都會去詢問，浪費CPU】
【缺點：輪詢的方式效率較低，不管集合是否為空，都會去詢問，浪費CPU】
手動啟用模組編譯：
--with-select_module
禁用模組編譯：
--without-select_module
※ 作業系統不支援epoll模型則預設編譯此模組
2. poll模型：
此模型算是select模型的升級版，運作方式差不多，select模型建立三個事件描述符集合，但poll模型則只需要建立一個集合，然後同時檢查三種事件是否發生，有就處理。
【優點：沒有最大的描述符集合限制】
【缺點：輪詢的方式效率較低，不管集合是否為空，都會去詢問，浪費CPU】 【缺點：Windows不支持此模型】
【優點：沒有最大的描述符集合限制】
【缺點：輪詢的方式效率較低，不管集合是否為空，都會去詢問，浪費CPU】 【缺點：Windows不支持此模型】
Nginx編譯代碼：
手動啟用模組編譯：
--with-poll_module
禁用模組編譯：
--without-poll_module
※ 作業系統不支援epoll模型則預設編譯此模組
3. epoll模型：
此模型是poll模型的變種，不會輪詢事件集合，而是建立一個待處理事件列表，再將該表發給內核，等到有事件發生，內核會通知函數庫，後進行處理
【優點：遠大於1024個描述符集合限制】 具體數值可察看此處
cat /proc/sys/fs/file-max
【優點：有事件才通知處理，效率提升，能高效處理高併發連接】
【缺點：開發複雜性較上述兩者高】
【缺點：Windows不支持此模型】
【缺點：開發複雜性較上述兩者高】
【缺點：Windows不支持此模型】
啟用模組編譯：
4. rtsig模型：
全稱：Real-Time Signal，即是即時訊號，此模型並不是常用的事件驅動模型，運作方式是透過系統核心建立一個rtsig佇列用於儲存事件，但最多只能儲存1024個事件訊號，因此如果超過1024個事件，就會發生溢位。 當溢位發生時，Nginx就會暫時停止rtsig模型，並啟用poll模型，來接手處裡事件，直到rtsig佇列全部清空為止，然後再次啟動rtsig模型。
【優點：主要支援Nginx特殊提供的即時訊號事件使用】
【缺點：最多只能存取1024個事件】
【缺點：發生溢位後就得切換模型，消耗資源】
【缺點：最多只能存取1024個事件】
【缺點：發生溢位後就得切換模型，消耗資源】
手動啟用模組編譯：
--with-rtsig_module
禁用模組編譯：
--without-rtsig_module
※ 預設不編譯此模組
5. kqueue模型：
主要適用於BSD系列作業系統及Mac OS X作業系統，此模型運作方式和epoll模型一樣，主要也是poll模型的變種，如果在BSD系統或MAC OS X系統使用NGINX的話，強烈建議使用此模型，以利提高Nginx Server的處理效能。
6. /dev/poll模型：
主要適用於Unix平台，主要用於Solaris711/99以上版本、HP/UX 11.22以上版本、IRIX 6.5.15以上版本及Tru64 UNIX 5.1A以上版本。
該模型是由Sun公司開發Solaris時所提出的事件驅動模型，它使用deb/poll裝置，開發人員可以將要監視的檔案描述符號加入這個裝置，然後透過ioctl()呼叫來取得事件通知，如果使用上述所提平台，強烈建議使用此模型，以利提高Nginx Server的處理效能。
7. eventport模型：
主要適用於Solaris 10以上版本
該模型也是由Sun公司開發Solaris時所提出的事件驅動模型。
筆者的話：
通常YUM安裝的固定模組已經很足夠使用了，況且NGINX會自動選擇最有效的事件模組，因此其實不太需要手動編譯模型，但仍然還需要修改config來指定工作模式。
use是個事件模組指令，用來指定Nginx的工作模式。
select和poll都是標準的工作模式
kqueue和epoll是高效的工作模式
kqueue和epoll是高效的工作模式
不同的是epoll用在Linux平臺上，而kqueue用在BSD系統中。
對於Linux系統，epoll工作模式是首選。
在作業系統不支援這些高效模型時才使用select。
在作業系統不支援這些高效模型時才使用select。
以下是筆者用epoll模組，壓力測試的結果
ab -n 10000 -c 10 http://localhost:80/index.html
模擬，同時1萬個訪問連線，總共要請求10次。
Time taken for tests: 1348.594 seconds
Requests per second: 7.42 [#/sec] (mean)
Requests per second: 7.42 [#/sec] (mean)
參考資料：
11會員
30內容數
留言0
查看全部
