溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點(diǎn)擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》

Nginx如此之快

發(fā)布時(shí)間:2020-07-27 13:40:15 來源:網(wǎng)絡(luò) 閱讀:176 作者:mdadmmeng 欄目:系統(tǒng)運(yùn)維
nignx的并發(fā)連接數(shù),一般優(yōu)化后,峰值能保持在 1~3w 左右。

Nginx如此之快

Nginx 的進(jìn)程模型

Nginx如此之快

Nginx 服務(wù)器,正常運(yùn)行過程中

1.多進(jìn)程:一個(gè) Master 進(jìn)程、多個(gè) Worker 進(jìn)程
2.Master 進(jìn)程:管理 Worker 進(jìn)程
3.對外接口:接收外部的操作(信號)
4.對內(nèi)轉(zhuǎn)發(fā):根據(jù)外部的操作的不同,通過信號管理 Worker
5.監(jiān)控:監(jiān)控 worker 進(jìn)程的運(yùn)行狀態(tài),worker 進(jìn)程異常終止后,自動重啟 worker 進(jìn)程
6.Worker 進(jìn)程:所有 Worker 進(jìn)程都是平等的
7.實(shí)際處理:網(wǎng)絡(luò)請求,由 Worker 進(jìn)程處理;
8.Worker 進(jìn)程數(shù)量:在 nginx.conf 中配置,一般設(shè)置為核心數(shù),充分利用 CPU 資源,同時(shí),避免進(jìn)程數(shù)量過多,避免進(jìn)程競爭 CPU 資源,增加上下文切換的損耗。

思考:

1.請求是連接到 Nginx,Master 進(jìn)程負(fù)責(zé)處理和轉(zhuǎn)發(fā)?
2.如何選定哪個(gè) Worker 進(jìn)程處理請求?請求的處理結(jié)果,是否還要經(jīng)過 Master 進(jìn)程?
Nginx如此之快

HTTP 連接建立和請求處理過程

1.Nginx 啟動時(shí),Master 進(jìn)程,加載配置文件
2.Master 進(jìn)程,初始化監(jiān)聽的 socket
3.Master 進(jìn)程,fork 出多個(gè) Worker 進(jìn)程
4.Worker 進(jìn)程,競爭新的連接,獲勝方通過三次握手,建立 Socket 連接,并處理請求

Nginx 高性能、高并發(fā)

1.Nginx 采用:多進(jìn)程 + 異步非阻塞方式(IO 多路復(fù)用 epoll)
2.請求的完整過程:
3.建立連接
4.讀取請求:解析請求
5.處理請求
6.響應(yīng)請求
7.請求的完整過程,對應(yīng)到底層,就是:讀寫 socket 事件

Nginx 的事件處理模型

request:Nginx 中 http 請求。

基本的 HTTP Web Server 工作模式:

1.接收請求:逐行讀取請求行和請求頭,判斷段有請求體后,讀取請求體
2.處理請求
3.返回響應(yīng):根據(jù)處理結(jié)果,生成相應(yīng)的 HTTP 請求(響應(yīng)行、響應(yīng)頭、響應(yīng)體)
Nginx 也是這個(gè)套路,整體流程一致。

Nginx如此之快

模塊化體系結(jié)構(gòu)

Nginx如此之快

nginx的模塊根據(jù)其功能基本上可以分為以下幾種類型:

1.event module: 搭建了獨(dú)立于操作系統(tǒng)的事件處理機(jī)制的框架,及提供了各具體事件的處理。包括ngx_events_module, ngx_event_core_module和ngx_epoll_module等。nginx具體使用何種事件處理模塊,這依賴于具體的操作系統(tǒng)和編譯選項(xiàng)。
2.phase handler: 此類型的模塊也被直接稱為handler模塊。主要負(fù)責(zé)處理客戶端請求并產(chǎn)生待響應(yīng)內(nèi)容,比如ngx_http_static_module模塊,負(fù)責(zé)客戶端的靜態(tài)頁面請求處理并將對應(yīng)的磁盤文件準(zhǔn)備為響應(yīng)內(nèi)容輸出。
3.output filter: 也稱為filter模塊,主要是負(fù)責(zé)對輸出的內(nèi)容進(jìn)行處理,可以對輸出進(jìn)行修改。例如,可以實(shí)現(xiàn)對輸出的所有html頁面增加預(yù)定義的footbar一類的工作,或者對輸出的圖片的URL進(jìn)行替換之類的工作。
4.upstream: upstream模塊實(shí)現(xiàn)反向代理的功能,將真正的請求轉(zhuǎn)發(fā)到后端服務(wù)器上,并從后端服務(wù)器上讀取響應(yīng),發(fā)回客戶端。upstream模塊是一種特殊的handler,只不過響應(yīng)內(nèi)容不是真正由自己產(chǎn)生的,而是從后端服務(wù)器上讀取的。
5.load-balancer: 負(fù)載均衡模塊,實(shí)現(xiàn)特定的算法,在眾多的后端服務(wù)器中,選擇一個(gè)服務(wù)器出來作為某個(gè)請求的轉(zhuǎn)發(fā)服務(wù)器。

常見問題剖析
Nginx vs. Apache

網(wǎng)絡(luò) IO 模型:

1.nginx:IO 多路復(fù)用,epoll(freebsd 上是 kqueue )
2.高性能
3.高并發(fā)
4.占用系統(tǒng)資源少
5.apache:阻塞 + 多進(jìn)程/多線程
6.更穩(wěn)定,bug 少
7.模塊更豐富

場景:

處理多個(gè)請求時(shí),可以采用:IO 多路復(fù)用 或者 阻塞 IO +多線程

IO 多路服用:一個(gè) 線程,跟蹤多個(gè) socket 狀態(tài),哪個(gè)就緒,就讀寫哪個(gè);
阻塞 IO + 多線程:每一個(gè)請求,新建一個(gè)服務(wù)線程

思考:IO 多路復(fù)用 和 多線程 的適用場景?

IO 多路復(fù)用:單個(gè)連接的請求處理速度沒有優(yōu)勢,適合 IO 密集型 場景,事件驅(qū)動
大并發(fā)量:只使用一個(gè)線程,處理大量的并發(fā)請求,降低上下文環(huán)境切換損耗,也不需要考慮并發(fā)問題,相對可以處理更多的請求;
消耗更少的系統(tǒng)資源(不需要線程調(diào)度開銷)
適用于長連接的情況(多線程模式長連接容易造成線程過多,造成頻繁調(diào)度)
阻塞IO + 多線程:實(shí)現(xiàn)簡單,可以不依賴系統(tǒng)調(diào)用,適合 CPU 密集型 場景
每個(gè)線程,都需要時(shí)間和空間;
線程數(shù)量增長時(shí),線程調(diào)度開銷指數(shù)增長

Nginx 最大連接數(shù)

基礎(chǔ)背景:

1.Nginx 是多進(jìn)程模型,Worker 進(jìn)程用于處理請求;
2.單個(gè)進(jìn)程的連接數(shù)(文件描述符 fd),有上限(nofile):ulimit -n
3.Nginx 上配置單個(gè) worker 進(jìn)程的最大連接數(shù):worker_connections 上限為 nofile
4.Nginx 上配置 worker 進(jìn)程的數(shù)量:worker_processes

因此,Nginx 的最大連接數(shù):

1.Nginx 的最大連接數(shù):Worker 進(jìn)程數(shù)量 x 單個(gè) Worker 進(jìn)程的最大連接數(shù)
2.上面是 Nginx 作為通用服務(wù)器時(shí),最大的連接數(shù)
3.Nginx 作為反向代理服務(wù)器時(shí),能夠服務(wù)的最大連接數(shù):(Worker 進(jìn)程數(shù)量 x 單個(gè) Worker 進(jìn)程的最大連接數(shù))/ 2。
4.Nginx 反向代理時(shí),會建立 Client 的連接和后端 Web Server 的連接,占用 2 個(gè)連接

思考:

每打開一個(gè) socket 占用一個(gè) fd

為什么,一個(gè)進(jìn)程能夠打開的 fd 數(shù)量有限制?

IO 模型

場景:

處理多個(gè)請求時(shí),可以采用:IO 多路復(fù)用 或者 阻塞 IO +多線程

IO 多路復(fù)用:一個(gè) 線程,跟蹤多個(gè) socket 狀態(tài),哪個(gè)就緒,就讀寫哪個(gè);
阻塞 IO + 多線程:每一個(gè)請求,新建一個(gè)服務(wù)線程

思考:
IO 多路復(fù)用 和 多線程 的適用場景?

IO 多路復(fù)用:單個(gè)連接的請求處理速度沒有優(yōu)勢
大并發(fā)量:只使用一個(gè)線程,處理大量的并發(fā)請求,降低上下文環(huán)境切換損耗,也不需要考慮并發(fā)問題,相對可以處理更多的請求;
消耗更少的系統(tǒng)資源(不需要線程調(diào)度開銷)
適用于長連接的情況(多線程模式長連接容易造成線程過多,造成頻繁調(diào)度)
阻塞IO + 多線程:實(shí)現(xiàn)簡單,可以不依賴系統(tǒng)調(diào)用。
每個(gè)線程,都需要時(shí)間和空間;
線程數(shù)量增長時(shí),線程調(diào)度開銷指數(shù)增長

select/poll 和 epoll 比較

詳細(xì)內(nèi)容,參考:

select poll epoll三者之間的比較

select/poll 系統(tǒng)調(diào)用:

//?select?系統(tǒng)調(diào)用?
?
int?select(int?maxfdp,fd_set?*readfds,fd_set?*writefds,fd_set?*errorfds,struct?timeval?*timeout);?
?
//?poll?系統(tǒng)調(diào)用?
?
int?poll(struct?pollfd?fds[],?nfds_t?nfds,?int?timeout);

select:

查詢 fd_set 中,是否有就緒的 fd,可以設(shè)定一個(gè)超時(shí)時(shí)間,當(dāng)有 fd (File descripter) 就緒或超時(shí)返回;
fd_set 是一個(gè)位集合,大小是在編譯內(nèi)核時(shí)的常量,默認(rèn)大小為 1024
特點(diǎn):
連接數(shù)限制,fd_set 可表示的 fd 數(shù)量太小了;
線性掃描:判斷 fd 是否就緒,需要遍歷一邊 fd_set;
數(shù)據(jù)復(fù)制:用戶空間和內(nèi)核空間,復(fù)制連接就緒狀態(tài)信息

poll:

解決了連接數(shù)限制:
poll 中將 select 中的 fd_set 替換成了一個(gè) pollfd 數(shù)組
解決 fd 數(shù)量過小的問題
數(shù)據(jù)復(fù)制:用戶空間和內(nèi)核空間,復(fù)制連接就緒狀態(tài)信息
epoll:event 事件驅(qū)動

epoll:event 事件驅(qū)動

事件機(jī)制:避免線性掃描
為每個(gè) fd,注冊一個(gè)監(jiān)聽事件
fd 變更為就緒時(shí),將 fd 添加到就緒鏈表
fd 數(shù)量:無限制(OS 級別的限制,單個(gè)進(jìn)程能打開多少個(gè) fd)

select,poll,epoll:

1.I/O多路復(fù)用的機(jī)制;
2.I/O多路復(fù)用就通過一種機(jī)制,可以監(jiān)視多個(gè)描述符,一旦某個(gè)描述符就緒(一般是讀就緒或者寫就緒),能夠通知程序進(jìn)行相應(yīng)的讀寫操作。
3.監(jiān)視多個(gè)文件描述符
4.但select,poll,epoll本質(zhì)上都是同步I/O:
5.用戶進(jìn)程負(fù)責(zé)讀寫(從內(nèi)核空間拷貝到用戶空間),讀寫過程中,用戶進(jìn)程是阻塞的;
6.異步 IO,無需用戶進(jìn)程負(fù)責(zé)讀寫,異步IO,會負(fù)責(zé)從內(nèi)核空間拷貝到用戶空間;

Nginx 的并發(fā)處理能力

關(guān)于 Nginx 的并發(fā)處理能力

并發(fā)連接數(shù),一般優(yōu)化后,峰值能保持在 1~3w 左右。(內(nèi)存和 CPU 核心數(shù)不同,會有進(jìn)一步優(yōu)化空間)


向AI問一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI