作者：張海
鏈接：https://www.zhihu.com/question/19761434/answer/160935301
來源：知乎
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
首先我們要了解系統的性能瓶頸在哪裏，一般來說網絡io速度和內存io接近，都遠高於磁盤io。假定一個接口請求返回數據100k（一般沒有這麼大，只是假定一個方便計算的值），10個併發請求就是1M，那麼全雙工千兆網卡（現在還有萬兆網卡，但成本太高，應用還不廣），可以支撐併發10000個請求，開雙網卡，理論的上限就是20000個併發請求。假設我們收到請求馬上就返回，那麼最高併發數就是我們上面計算的結果，但是，問題在於，應用服務器做不到馬上返回，因爲它有很多業務邏輯需要執行處理，比如給用戶發推送發短信發郵件，本地磁盤寫日誌，請求數據庫增刪改查，調用微信的登錄接口等等等等，都附加了各個層面的io。所以第一層的優化，我們會盡量優化應用服務自身，把發推送發短信發郵件的活推到隊列，讓別的服務器去幹。這個一般用內存隊列，io很高。開多線程或者協程的方式異步寫日誌，但再怎麼優化，磁盤io的上限突破不了，這個io很低。還有更激進的方案，乾脆日誌也寫內存，或者通過內網網絡同步到別的服務器上，可以更優化。數據庫複用連接池，減少連接和斷開的時間開銷。查詢語句儘量優化，減少等待數據庫操作的時間。當然，再怎麼優化，一樣有個上限。調用微信的登錄接口等外部接口，這個就更難辦了，受制於人，除了tcp連接池複用能稍微優化一點點，完全是取決於外部條件。木桶理論取最短板，所有這些條件裏，總有最慢最落後的那個。假如拖後腿的這個，最佳狀態也只能優化到支持2000個併發，那就尷尬了，本來能支持20000個請求的系統，只能用到1/10性能。（ 當然也可以在dns對應不同ip方式分佈請求，但是dns層面的分佈更復雜更麻煩，因爲dns緩存的原因，請求也不能均勻分佈，而且ip地址也是越來越稀缺的資源，沒有背景沒有後臺的，搞這麼多ip也不容易啊 ）單個公網ip算一個節點的話，這個節點本來的潛力是響應20000個併發請求，實際在應用層面只能到2000併發，潛力還未發掘啊。這個時候，就是反向代理起到用武之地的時候了。首先一個反向代理的服務器拋開所有業務層的東西，只單純的接下請求再返回，那麼可以支持到20000併發了。接下來應用層面誰來處理？找來10個小弟，轉發給他們，每人2000正好。這樣這個節點系統雖然性價比只有10/11，但是性能潛力好歹挖盡了。這就是反向代理的作用了。
這個單機環境下是沒啥作用的。在集羣環境下，Nginx可以支持負載均衡，使網站獲得更好的性能和穩定性。
Nginx的快速， 其實在於Linux上優秀網絡模型epoll 的支持
而傳統Select模型很低效