Nginx 軟體層面加強Nginx效能優化的面試問答和解決方案

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