nginx為什麼比apache快？
先總結的說幾個概念：
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技術文章，請造訪Nginx使用教學專欄！
以上是nginx為什麼比apache快的詳細內容。更多資訊請關注PHP中文網其他相關文章！
