1：在高併發的情況下nginx比apache快，低併發體現不明顯
2：快的原因得益於nginx的epoll模型
apache是多執行緒或者多程序，在工作的時候，當來了乙個http響應，乙個程序接收（listen）–>識別處理—>返回請求，在此過程中，乙個程序全部處理，apche 對於套接字的i/o，讀或者寫，但是讀或者寫都是阻塞的，阻塞意味著程序就得掛起進入sleep狀態，那麼一旦連線數很多，apache必然要生成更多的程序來響應請求，一旦程序多了，cpu對於程序的切換就頻繁了，很耗資源和時間，所以就導致apache效能下降了，說白了就是處理不過來這麼多程序了。
nginx採用epoll模型，非同步非阻塞。對於nginx來說，把乙個完整的連線請求處理都劃分成了事件，乙個乙個的事件。比如accept（）， receive（），磁碟i/o，send（）等，每部分都有相應的模組去處理，乙個完整的請求可能是由幾百個模組去處理。真正核心的就是事件收集和分發模組，這就是管理所有模組的核心。只有核心模組的排程才能讓對應的模組占用cpu資源，從而處理請求。拿乙個http請求來說，首先在事件收集分發模組註冊感興趣的監聽事件，註冊好之後不阻塞直接返回，接下來就不需要再管了，等待有連線來了核心會通知你(epoll的輪詢會告訴程序)，cpu就可以處理其他事情去了。一旦有請求來，那麼對整個請求分配相應的上下文（其實已經預先分配好），這時候再註冊新的感興趣的事件(read函式)，同樣客戶端資料來了核心會自動通知程序可以去讀資料了，讀了資料之後就是解析，解析完後去磁碟找資源（i/o），一旦i/o完成會通知程序，程序開始給客戶端發回資料send()，這時候也不是阻塞的，呼叫後就等核心發回通知傳送的結果就行。整個下來把乙個請求分成了很多個階段，每個階段都到很多模組去註冊，然後處理，都是非同步非阻塞。非同步這裡指的就是做乙個事情，不需要等返回結果，做好了會自動通知你。
在網上找到了乙個例子：
可以舉乙個簡單的例子來說明apache的工作流程，我們平時去餐廳吃飯。餐廳的工作模式是乙個服務員全程服務客戶，流程是這樣，服務員在門口等候客人(listen)，客人到了就接待安排的餐桌上(accept)，等著客戶點菜(request uri)，去廚房叫師傅下單做菜（磁碟i/o），等待廚房做好（read），然後給客人上菜(send)，整個下來服務員(程序)很多地方是阻塞的。這樣客人一多（http請求一多），餐廳只能通過叫更多的服務員來服務（fork程序），但是由於餐廳資源是有限的（cpu），一旦服務員太多管理成本很高（cpu上下文切換），這樣就進入乙個瓶頸。
再來看看nginx得怎麼處理？餐廳門口掛個門鈴（註冊epoll模型的listen），一旦有客人（http請求）到達，派乙個服務員去接待（accept），之後服務員就去忙其他事情了（比如再去接待客人），等這位客人點好餐就叫服務員（資料到了read()），服務員過來拿走選單到廚房（磁碟i/o），服務員又做其他事情去了，等廚房做好了菜也喊服務員（磁碟i/o結束），服務員再給客人上菜（send()），廚房做好乙個菜就給客人上乙個，中間服務員可以去幹其他事情。整個過程被切分成很多個階段，每個階段都有相應的服務模組。我們想想，這樣一旦客人多了，餐廳也能招待更多的人。
nginx為什麼比Apache支援高併發？？？
最開始接觸程式設計時，使用的是apache伺服器，後來隨著 使用者訪問量的增加，考慮高併發是必不可少的環節，越來越多的公司使用nginx伺服器。我們公司最近也打算更換nginx伺服器。那麼nginx和apache有哪些異同點呢，nginx為什麼比apache支援高併發呢？首先，先看一下各自使用的io...
Nginx支援比Apache高併發的原因
1.先從各自使用的多路復用io模型說起 select模型 apache使用，由於受模組等限制，用的不多 單個程序能夠 監視的檔案描述符的數量存在最大限制 select 所維護的 儲存大量檔案描述符的資料結構 隨著檔案描述符數量的增長，其在使用者態和核心的位址空間的複製所引發的開銷也會線性增長 由於網...
Nginx支援比Apache高併發的原因
1.先從各自使用的多路復用io模型說起 select模型 apache使用，由於受模組等限制，用的不多 單個程序能夠 監視的檔案描述符的數量存在最大限制 select 所維護的 儲存大量檔案描述符的資料結構 隨著檔案描述符數量的增長，其在使用者態和核心的位址空間的複製所引發的開銷也會線性增長 由於網...