任何一個任務都可以分解為三個要素，即“誰”，“什麽時間”，”幹什麽“。如果我們把這三個要素畫在一個笛卡爾坐標系中，就顯得很有意思了：

我以單CPU多任務操作系統為例，來看一個簡單的Web服務是如何映射到上圖的：

一般情況下都是按照上圖處理的。每來到一個連接，便會新建一個進程或者線程單獨服務那個連接，連接結束後，進程或者線程隨即銷毀。

??然而，鑒於進程/線程的創建會有比較可觀的系統開銷，所以說一般會預創建比較多的進程或者線程，然後為新建的連接分配一個即可，連接結束後進程或者線程便回到空閑資源池中了。

??顯然，這種優化會大大降低進程，線程的創建，銷毀的開銷，我們知道這種開銷主要集中於數據結構的分配與回收，內核基礎設施的刷新等。再看上圖，可以看得出，每一個進程就像一塊板子一樣插在Who，When，What

??除了刀片插拔的開銷，還有另外一種開銷，那就是切換的開銷，這裏就不具體展開了，一般人都知道進程，線程切換所要付出的操作系統級別的代價。

??特別是當同時在線的連接數據巨大的時候，比如10萬量級，就意味著有10萬量級的進程或者線程要在單一的系統中頻繁切換…怎麽辦？

按照能量守恒定律，只要CPU維持100%的運轉，它單位時間內完成的工作量就是一定的，想最大化吞吐最好的辦法就是只要讓幹一件事，而不是搞多個任務頻繁切換。我們知道多任務分時調度只是一種假象，代價是切換開銷引起的吞吐量降低，收益是高品質低時延的交互性。使用Linux的都知道，一般情況下，服務器的內核HZ都是100或者250，而桌面系統的內核HZ都是1000，這意味著對於服務器而言，吞吐相比交互的響應性更重要，理解了這個例子，就能理解我接下來要說的了。

還記得我曾經大力推崇的nf-HiPAC，以及我自己設計的DxRPro++，iptables規則優化等故事裏關於優化的根本原則嗎？就是換一種切法。好吧，這次我們把Web服務器處理單條連接的整個處理流程切分成兩個部分，而不再按照連接來切分，看看能不能避免創建多個進程或者線程。

??先上圖再解釋：

非常Perfect！

??整個系統就只有兩個進程，一個進程處理所有的新建連接，另一個進程處理真正的HTTP邏輯，換了一種切分方法，意味著只需要兩個進程就夠了，就這樣，切換開銷完美避免。在這裏，其實還可以說得更多。

??首先，連接管理進程依靠Linux內核中高效的epoll機制可以非常好的應對海量新建連接，畢竟該進程只是把新建連接pendding給後面的邏輯處理進程，所以處理是非常高效的，通過pendding可以把對CPU的時間要求轉換為內存的空間要求，這正是換一種切法帶來的直接收益。

??其次，如果你懷疑連接處理進程能否真正應對海量新建連接，那麽你可以了解一下泊松分布的知識，新建連接分布是一個泊松分布，它並不是持續海量，你的系統只需要調優到其到達率的數學期望值稍高一點就足夠了！當然，如果遇到了DDoS，那便可以另說，我有專門討論DDoS的文章，本文不說這個。

??另外，我說一點，其實上面兩個圖正是體現了Apache和Nginx之間的區別。

??Nginx為什麽比Apache在應對高並發是表現更好？其實就用因為其獨立的異步的事件處理，當一個連接處理進入IO等待的時候進程並不阻塞，同一個進程就可以去處理別的連接，這就大大減小了系統進程的數量，從而凈節省了系統開銷。如果讓Apache去應對泊松分布的連接到達，那就只能寄希望於內核了…當然，Apache也有優點，就是它的編程模型以及可擴展模塊。

??經理喜歡Apache，極客喜歡Nginx。

??如果有時間，我會把上面關於“誰”，“什麽時間”，”幹什麽“的模型的玩法全部展示一遍，比如它的高度代表什麽，它的寬度和厚度分別代表什麽等等，另外如果是多個CPU，這個圖又該怎麽畫…是不是在多CPU系統中，又要再加一個H呢？這樣就成了“誰”，“什麽時間”，在哪裏，”幹什麽“(Who，When，Where，What)了。

??周五上午走了7公裏健步行，微信運動統計步數正常一萬步左右吧，然而我通過搖手機的方式為我們團隊平均成績增加了近900步…第二天醒來手有點酸…這就是teamwork吧，唉。可能是因為上周《龍珠超》停播了一周，然後我就改看《古惑仔》了吧，前者都是單打獨鬥，後者就是teamwork了，也就學會了？嗯，也是，反正周五跟同事們一起喝完酒是比自己喝完酒爽很多的…

————–勘誤與補遺————–
王姐姐如是說：Nginx並不比Apache好，Apache適合做服務器，而Nginx只適合做代理。不過確實如此。

再分享一下我老師大神的人工智能教程吧。零基礎！通俗易懂！風趣幽默！還帶黃段子！希望你也加入到我們人工智能的隊伍中來！https://blog.csdn.net/jiangjunshow

網絡服務的兩種處理模型 Nginx為什麽比Apache好