Nginx 軟件層面加強Nginx性能優化的面試問答和解決方案
去年我去愛卡汽車面試PHP，一輪和二輪面的都不錯，在三輪面到Nginx的時候很多問題當時不知道怎麼回答，確實沒有深入學習過，花了一段時間的學習，終於能解答Nginx高性能優化的問題了，10月24號爲了獲得程序員勳章，發佈了半個優化筆記，瀏覽到了1000+，受到這個鼓舞，我抽時間在仔細整理下關於Nginx性能優化的問題，我們從軟件說起。
從軟件層面提升硬件使用效率
- 增大CPU的利用率
- 增大內存的利用率
- 增大磁盤I/O的利用率
- 增大網絡帶寬的利用率
增大CPU的利用率
1、增大Nginx使用CPU的有效時長
- 能夠使用全部CPU資源
- master-worker多進程架構
- worker進程數量應當大於等於CPU核數
- Nginx進程間不做無用功浪費CPU資源
- worker進程不應在繁忙時，主動讓出CPU
- worker程間不應由於爭搶造成資源耗散
- worker進程數量應當等於CPU核數
- worker進程不應調用_些店1導致主動讓出CPU
- 拒絕類似的第三方模塊
- 不被其他進程爭搶資源
- 提升優先級佔用CPU更長的時間
- 減少操作系統上耗資源的非Nginx進程
設置worker進程數的技巧和原理：worker進程數量應當大於等於CPU核數，並不是說worker進程數量設置的越大越好，他正確的設置方法應該是CPU核數和CPU核數的倍數，這樣在CUP運行時(宏觀上並行，微觀上串行,把進程的運行時間分爲一段段的時間片),這樣能最大的利用CPU的資源。
Syntax: worker processes number auto;
Default: worker_processes 1;
Context: main
但不是設置的數值越大就越好，CPU的執行還受到運行時間片的影響，OS調度系統依次選擇每個進程，最多執行時間片指定的時長，因爲業務、或者是硬盤處理速度的不匹配，阻塞API引發的時間片內主動讓出CPU要在減少進程間切換下功夫。
程間切換，就是是指CPU從一個進程或線程切換到另一個進程或線程。查看上下文切換次數的命令有Vmstat,Dstat,Pidstat -w。
設置Priority動態優先級，決定CPU時間片的大小，設置worker進程的靜態優先級。
Syntax: worker priority number;
Default: worker_priority 0;
Context: main
CPU依託NUMA架構，我們常說一級緩存，二級緩存，三級緩存，Nginx提高性能的點在於提升CPU緩存命中率，綁定worker到指定CPU。
worker_processes 4;
worker_cpu_affinity 01 10 01 10;
滑動窗口:Nginx在網絡傳輸上的優化
活動窗口功能：用於限制連接的網速，解決報文 舌L序和可靠傳輸問題，Nginx中limitrate等限速指令皆 依賴它實現，由操作系統內核實現，連接兩端各有發送窗口與接收窗。
nginx的超時指令與滑動窗口，主動斷開連接，釋放網絡傳輸資源。
兩次讀操作間的超時
Default: client_body_timeout 60s;
Context: http, server, location
兩次寫操作間的超時
Default: send_timeout 60s;
Context: http, server, location
以上兩者兼具:
Default: proxy_timeout 10m;
Context: http, server, location
主動建立連接時應用層超時時間，儘早釋放CPU資源。
proxy_connect_timeout 60s;
Context:http, server, location
也不是說Nginx設置的處理鏈接數越多越好，可能會造成服務器的SYN攻擊。當SYN隊列滿後，新的SYN不進入隊列，計算出cookie再以 SYN+ACK中的序列號返回客戶端，正常客戶端發報文時，服 務器根據報文中攜帶的cookie重新恢復連接。
net.ipv4.tcp_syncookies = 1
設置worker進程最大連接數量，包括Nginx與上游、下游間的連接。
Syntax: worker_connections_number;
Default: worker_connections 512;
Context: events
Nginx在增大網絡帶寬的利用率上的優化
當Nginx處理完成調用close關閉連接後，若接收緩衝區仍然收到客戶端發來的 內容，則服務器會向客戶端發送RST包關閉連接,導致客戶端由於收到RST而忽略了http response。
Default: lingering_close on;
Context: http, server, location
當功能啓用時，最長的讀取用戶請求內容的時長，達到後立刻關閉連接。
Default: lingering_time 30s;
Context: http, server, location
當功能啓用時，最長的讀取用戶請求內容的時長，達到後立刻關閉連接。
Default: lingering_timeout 5s;
Context: http, server, location
以RST代替正常的四次握手關閉連接,當其他讀、寫超時指令生效引發連接關閉時，通過發送RST立刻釋放端口、內 存等資源來關閉連接。
Default: reset_timedout_connection off;
Context: http, server, location
TLS/SSL優化握手性能,
ssl_session_cache off | none | [builtin[:size]] [shared:name:size];
Context: http, server
off 不使用Session緩存，且Nginx在協議中明確告訴客戶端Session緩存不被使用
none 不使用Session緩存
builtin 使用Openss啲Session緩存，由於在內存中使用，所以僅當同一客戶端的兩次連接都命中到 同一 worker進程時，Session緩存纔會生效
shared:name:size 定義共享內存，爲所有worker進程提供Session緩存服務。IMB大約可用於4000個Session
HTTP長連接,減少握手次數,通過減少併發連接數減少了服務器資源的消耗,降低TCP擁塞控制的影響
Default: keepalive_requests 100;
Context: http, server, location