Nginx支持比Apache高併發的緣由

1.先從各自使用的多路複用IO模型提及：
  
select模型：（apache使用，因爲受模塊等限制，用的很少）
  

1. 單個進程可以 監視的文件描述符的數量存在最大限制
2. select()所維護的 存儲大量文件描述符的數據結構 ，隨着文件描述符數量的增加，其在用戶態和內核的地址空間的複製所引起的開銷也會線性增加
3. 因爲網絡響應時間的延遲使得大量TCP鏈接處於非活躍狀態，但調用select()仍是會對 全部的socket進行一次線性掃描 ，會形成必定的開銷

poll：

poll是unix沿用select本身從新實現了一遍，惟一解決的問題是poll 沒有最大文件描述符數量的限制

epoll模型：（nginx使用）

epoll帶來了兩個優點，大幅度提高了性能：

1. 基於事件的就緒通知方式 ，select/poll方式，進程只有在調用必定的方法後，內核纔會對全部監視的文件描述符進行掃描，而epoll事件經過epoll_ctl()註冊一個文件描述符，一旦某個文件描述符就緒時，內核會採用相似call back的回調機制，迅速激活這個文件描述符，epoll_wait()便會獲得通知
2. 調用一次epoll_wait()得到就緒文件描述符時，返回的並非實際的描述符，而是一個表明就緒描述符數量的值，拿到這些值去epoll指定的一個數組中依次取得相應數量的文件描述符便可，這裏使用內存映射（mmap）技術， 避免了複製大量文件描述符帶來的開銷

固然epoll也有必定的侷限性， epoll只有Linux2.6纔有實現 ，而其餘平臺都沒有，這和apache這種優秀的跨平臺服務器，顯然是有些背道而馳了。

簡單來講epoll是select的升級版，單進程管理的文件描述符沒有最大限制。但epoll只有linux平臺可以使用。做爲跨平臺的Apache沒有使用。

2.再看一下Apache經常使用的兩種併發策略：

      1） perfork模式的工做原理：  
                    當Apache被啓動時，Apache會自動建立StartServers個進程，而且盡力將空閒進程數保持在MinSpareServers和MaxSpareServers之間。
                    若是空閒進程小於MinSpareServers，Apache將會以大約每秒1個的速度新建進程。
                    若是空閒進程小於MaxSpareServers，Apache將會刪除多餘的空閒進程，釋放服務器資源。
                    進程數的最大值由MaxClients控制，在Apache1.3中最大隻能設置爲256，但在Apache2.0中，能夠經過在配置開頭增長ServerLimit項目來突破256的限制，此時必須MaxClients  ≤ ServerLimit ≤ 20000
                    MaxRequestsPerChild用來控制每一個進程在處理了多少次請求以後自動銷燬，這個參數能夠設置爲0表示無限（即不銷燬進程）

     2） worker模式的工做原理：
            由主控制進程生成「StartServers」個子進程，每一個子進程中包含固定的ThreadsPerChild線程數，各個線程獨立地處理請求。
            一樣，爲了避免在請求到來時再生成線程，MinSpareThreads和MaxSpareThreads設置了最少和最多的空閒線程數；而MaxClients設置容許的最大線程總數。
            若是現有子進程中的線程總數不能知足負載，控制進程將派生新的子進程。
           每一個子線程處理服務請求次數由MaxRequestPerChild定義。 缺省的設置值爲0，即響應無限此請求。
           默認生成3個子進程來處理請求。

  兩種策略的缺陷：
        perfork模式：每個鏈接建立一個進程，每一個進程內單線程。對於一個負載相對較高的網站來講，256的進程限制是不夠的，若是服務器已經達到256的極限，那麼接下去的訪問就須要排隊，這也就是爲何某些服務器負載不高，可是訪問卻很慢的緣由之一。

        worker模式：也是多進程處理，也會建立多個進程和多個線程，若是進程數達到管理員設置的閥值，則會拒絕新的請求。
       兩種模式都會建立多個進程或線程，而每一個進程或線程都會爲其分配cpu和內存（線程要比進程小的多，因此worker支持比perfork高的併發），併發過大會榨乾服務器資源。

3.Nginx的工做原理：

      Nginx並不會爲每個的web請求建立新的進程，相反，管理員能夠配置Nginx主進程的工做進程的數量（一個常見的作法是爲每個CPU配置一個工做進程）。全部這些進程都是單線程的。
      每個工做進程能夠處理數千個併發的請求。它經過一個線程來異步非阻塞的完成了這些工做（epoll），而沒有使用多線程的編程模型。

 
  nginx的優點：

      採用單線程來異步非阻塞處理請求，不會爲每一個請求分配cpu和內存資源，節省了大量資源，同時也減小了大量的CPU的上下文切換。因此才使得Nginx支持更高的併發。