問題： 對nginx 而言， 乙個工作程序，只建立乙個工作執行緒，但可以開啟多個檔案。
用ps -ef -l 可以檢視， -l 可顯示lwp(light weight process) 和 nlwp(number os light weigh process) 列
難道對方用查詢方式看結果？還是採用通知？
下面是查詢的結果， 略加整理。原來linux2.6 核心已經支援一種高效的併發訪問。
————————————————————————————
nginx採用的是單執行緒的方式
————————————————————————————
如果在linux下，最好的模型自然是epool（effectiveepoll?)
2塊1000m網絡卡，10k客戶端，每個客戶端的頻寬是 2000/10000=200k，這是理論值，勉強可行。
————————————————————————————
純粹執行緒模型的缺陷！
————————————————————————————
考慮 10k個客戶端，需要10k個執行緒。
考慮到每個程序3g的使用者空間，那麼每個執行緒的空間是3000m/10k=300k，
只能說非常勉強可以執行（每個執行緒的cruntime大約需要2-3k空間）。
但是大量的執行緒排程會極大的減緩系統效率。
再考慮一下多個程序的模型，每個程序建立多個執行緒。
其實與純粹的執行緒模型差異不大，不過是每個執行緒的使用者空間不受太大限制。
大量的執行緒排程帶來的巨大效能損耗會使得整個系統效率及其低下。
當然，這種模型也不是一無是處，對於客戶端數目不多的情況，比如ftp伺服器，這種模型是非常合適的
————————————————————————————
epoll模 型。
————————————————————————————
了解select模型的人都知道，select每個控制代碼只能支援64個socket
poll模型則是一種事件觸發的模型，沒有64個socket的限制
由於select和poll在連線數增加時，效能急劇下降。這有兩方面的原因：
首先作業系統面對每次的select/poll操作，都需要重新建立乙個當前執行緒的關心事件列表，
並把執行緒掛在這個複雜的等待佇列上，這是相當耗時的。
其次，應用軟體在select/poll返回後也需要對傳入的控制代碼列表做一次掃瞄來dispatch，這也是很耗時的。
這兩件事都是和併發數相關，而i/o事件的密度也和併發數相關，導致cpu佔用率和併發數近似成o(n^2)的關係。因為以上的原因，
*nix的hacker們開發了epoll,kqueue,/dev/poll這3套利器來幫助大家，
其中epoll是linux的方案，kqueue是freebsd的方案，/dev/poll是最古老的solaris的方案
簡單的說，這些api做了兩件事：
1.避免了每次呼叫select/poll時kernel分析引數建立事件等待結構的開銷，
kernel維護乙個長期的事件關注列表，應用程式通過控制代碼修改這個列表和捕獲i/o事件。
2.避免了select/poll返回後，應用程式掃瞄整個控制代碼表的開銷，kernel直接返回具體的事件列表給應用程式。
要使用epoll模型，首先必須有linux2.6的核心
epoll是對poll模型的乙個改造，讓乙個poll控制代碼可以同時支援多個socket控制代碼，
好處是將大量poll控制代碼的事件探測機制放到核心中處理，大大減少了將資料從核心態拷貝到使用者態的次數，從而提高效率。
閱讀linux的原始碼可以看到，epoll的內部使用的是乙個hashmap，hashmap中存放poll物件，
所以從根本上來說，epoll模型是一種更好的poll模型(我一直理解為effectivepoll)。
在接觸具體api之前，先了解一下邊緣觸發(edge trigger)和水平觸發(level trigger)的概念。
邊緣觸發是指每當狀態變化時發生乙個io事件，水平觸發是只要滿足條件就發生乙個io事件。
舉個讀socket的例子，假定經過長時間的沉默後，現在來了100個位元組，
這時無論邊緣觸發和條件觸發都會產生乙個read readynotification通知應用程式可讀。
應用程式讀了50個位元組，然後重新呼叫api等待io事件。
這時條件觸發的api會因為還有50個位元組可讀從而立即返回使用者乙個read readynotification。
而邊緣觸發的api會因為可讀這個狀態沒有發生變化而陷入長期等待。
因此在使用邊緣觸發的api時，要注意每次都要讀到socket返回ewouldblock為止，否則這個socket就算廢了。
而使用水平觸發的api時，如果應用程式不需要寫就不要關注 socket可寫的事件，
否則就會無限次的立即返回乙個write readynotification。
大家常用的select就是屬於水平觸發這一類。epoll用到的所有函式都是在標頭檔案sys/epoll.h中宣告的
nginx 採用了linux 的epoll 模型來提高併發性。
Nginx（十） 程序模型及工作原理
1.nginx程序模型 nginx是乙個master和worker的模型。master主要用來管理worker程序，master就比作老闆，worker就是打工仔，master指揮worker來做事情。下圖是nginx的程序模型 master程序 1.接收外界的訊號，例如 kill quit，kil...
Nginx程序模型
這篇主要是閱讀這篇博文的筆記。nginx採用的也是大部分http伺服器的做法，master，worker模型，基本的事件處理都是放在worker中，master負責一些全域性初始化，以及對worker的管理。nginx中的master和worker之間是通過socketpair來實現的，每次fork...
Nginx程序模型
目錄 1.nginx管理 工作程序模式 2.驚群 問題 為了支援現在流行的多cpu和多核架構，nginx使用了管理程序和工作程序的設計。架構設計如下圖所示 管理程序為工作程序的父程序，負責外部指令的接收，工作程序的狀態監管，負載均衡等 工作程序負責客戶端請求的處理和響應，工作程序一般是按照cpu的核...