之前我們談到了nginx的讀寫事件,這些網絡讀寫事件究竟是怎么應用到nginx上的尼?
還有我們談到nginx使用了一個連接池來增加它的資源的利用率,下面我們來看下nginx的連接池究竟是怎么來使用的?
我們來看下上圖中的右邊的圖,每一個worker進程里面都有一個獨立的ngx_cycle_t這樣的一個數據結構;
現在不要對它里面的細節來糾結,這里有三個主要的數組需要看一下;
其中connections 這就是我們所謂的連接池;它指向的我們這個數組有多大尼?我們可以看下有一個配置項:
打開nginx的官網在文檔中找到Core functionality
也就是核心功能,這個核心功能有一個選項worker_connections;
默認會有一個512大小的數組,這里的每一個數組就是一個連接,可以看到512其實是非常小的,因為我們nginx動則處理萬,十萬,百萬級的計算,所以我們往往是需要去修改的;而且官方提示很清楚,這個連接不止去用於客戶端的連接,也用於面向上有服務器的連接,所以如果我們做反向代理的時候,每個客戶端意味着消耗我們兩個connections;
每一個連接自動的對應一個讀事件和一個寫事件,所以在ngx_cycle_t中還有個write_events;它們指向的數組的大小也跟worker_connections這個配置是一樣的;所以connections連接事件,讀事件,寫事件是通過序號對應起來的;所以我們在考慮nginx能夠釋放多大性能的時候,首先要保證worker_connections足夠我們使用;但是worker_connections所指向的數組,同時影響了我們所打開的內存,當我們配置了更大的worker_connections的時候,也就意味着nginx使用了更大的內存;所以每一個connections連接到底使用了多大的內存尼?
我們可以看一下,每一個ngx_connection_s這樣的一個結構體在64位操作系統中它占用的字節數大約是232字節;具體會因nginx版本不同,可能會有微小的差異;
每一個ngx_connection_s這樣的一個結構體它對應着兩個事件,一個讀事件,一個寫事件,我們之前談到網絡事件談到了它的許多特性;
那么在nginx中每一個事件對應一個結構體叫做ngx_event_s;每個事件對應的結構體它所對應的字節數是96字節;
所以我們在使用一個連接的時候它大概消耗的字節為(232+96)*2;我們的worker_connections配置的越大,那么初始化的時候就會預分配這么多的內存;
我們再來看下ngx_event_s里面有哪些成員?
這里我們比較關注的是handler這是一個回調方法;也就是說很多第三方模塊會把這個handler設置為自己的實現;這里還有個timer,也就是說當我們對http請求做讀超時和寫超時時候等等設置的時候,其實是在操作讀事件和寫事件中的tmer;這個timer其實就是nginx實現超時定時器,也就是基於rbtree中的紅黑樹去實現的結構體;這里定時器其實也是可配的,這里我們看下它的配置;
在官方文檔ngx_http_core_module 模塊中
比如client_header_timeout:
默認設置為60s,其實這個60s也就是在我們剛剛某個連接上,在准備讀它的header時,我們在它的讀事件上添加個60s的定時器;
當多個事件形成隊列的時候我們可以使用ngx_queue_t;
我們再來看下ngx_connections_s 每個連接有些什么樣的成員?
read 和 write分別是它的讀寫事件;
recv和send是它的一個抽象的操作系統的底層方法;怎么樣發送和接受;
這里還有一個變量叫sent (off_t:表示無符號的整型)它表示這個連接上已經發送了多少字節,也就是在配置中經常使用到的$bytes_sent
還是在ngx_http_core_module 模塊中 我們先找到它的內置變量;
$bytes_sent:它表示向客戶端發送了多少字節;
通常在access.log記錄nginx處理了哪些請求中我們可以記錄這么一個變量,我們在ngixn.conf配置中添加了這么一個變量
總結:當我們需要配置高並發的nginx的時候,必須把connections的數目配置的足夠大,而每個connections將對應兩個event,都會消耗一定的內存,還有nginx的許多結構體中,它們的一些成員和我們的內置變量是可以對應起來的;