在單機的情況下的壓測結果：
分佈式的壓測結果：
雖然tps還是比較少，但是還是有提升，主要是因爲數據庫的服務器的配置是很低的，所以擴展這裏其實就更有幫助，這裏就不再修改了。 
而對於nginx和服務之間的連接還是短連接，所以還是有性能消耗，接下來我們把nginx的連接改成長連接：
由於數據庫服務器配置問題，所以數字上看不出太多變化，如果配置好的機器，變化是非常大的。
爲什麼nginx性能那麼高？
epoll多路複用完成非阻塞式io操作：傳統java開發都會使用bio模型，也就是阻塞進程式模型。接下來再介紹一下linux select模型，他不是傳統意義上客戶端訪問服務端，調用socket.write，而是服務端監聽例如100個客戶端，當某幾個客戶端狀態發生變化的時候，喚醒自己並且輪詢客戶端處理髮生變化的幾個。這個的壞處是輪詢遍歷效率不高，且最多監聽1024個客戶端。對於很多的服務器那麼就力不從心了。所以在linux2.6以後就誕生了epoll模型，他也是監聽客戶端連接，但會設置回調函數，如果有變化則直接喚醒自己並執行回調函數，且理論上沒有限制。
master worker進程模型使得可以做平滑的重啓，使客戶端不會被斷開。接下來看下面這張圖：
請求到master進程後，由master進程發給worker進程來進行處理。
看下進程：
那麼客戶端發送請求到底連接哪個worker呢？client請求發送後，worker進程會搶佔資源，應用互斥鎖鎖住資源，然後通過三次握手建立連接，建立好以後，往後這個客戶端的請求都由這個進程來處理。 master進程只處理管理員的信號，當配置或命令發生變化的時候，master會馬上感知到並通知worker，並new出新的worker進程，並將老的worker進程的連接轉移到新的worker上，滿足客戶端請求。所以就算重啓，用戶也不用斷開。
協程機制
由於worker模型是單線程的，對於大量請求如何完成異步化操作？協程是比線程更小的模型，它依附於線程的內存模型，切換開銷更小。如果協程程序遇到阻塞，nginx的協程機制會自動的把協程的權限剝奪，並在線程中掉另一個非阻塞的線程去執行，代碼同步編寫非常簡單，而且由於協程依附於線程，所以是串行的，不需要加鎖。