Nginx配置優化及深入講解,大家可以聽一下
隨著訪問量的不斷增加，需要對Nginx和內核做相應的優化來滿足高並發用戶的訪問，那下面在單臺Nginx服務器來優化相關參數。
1) Nginx.conf配置優化：
worker_processes 8;
nginx進程數，建議按照cpu數目來指定，一般為它的倍數。
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000
00100000 01000000 10000000;
為每個進程分配cpu，上例中將8個進程分配到8個cpu，當然可以寫多個，或者將一
個進程分配到多個cpu。
worker_rlimit_nofile 102400;
這個指令是指當一個nginx進程打開的最多文件描述符數目，理論值應該是最多打
開文件數（ulimit -n）與nginx進程數相除，但是nginx分配請求並不是那麽均勻
，所以最好與ulimit -n的值保持一致。
use epoll;
使用epoll的I/O模型。epoll是Linux內核為處理大批量文件描述符而作了改進的
poll，它能顯著提高程序在大量並發連接中只有少量活躍的情況下的系統CPU利用
率。
worker_connections 102400;
每個進程允許的最多連接數，理論上每臺nginx服務器的最大連接數為
worker_processes*worker_connections。
keepalive_timeout 60;
keepalive超時時間，客戶端到服務器端的連接持續有效時間,當出現對服務器的後
繼請求時,keepalive-timeout功能可避免建立或重新建立連接。
client_header_buffer_size 4k;
客戶端請求頭部的緩沖區大小，這個可以根據你的系統分頁大小來設置，一般一個
請求的頭部大小不會超過1k，不過由於一般系統分頁都要大於1k，所以這裏設置為
分頁大小。分頁大小可以用命令getconf PAGESIZE取得。
open_file_cache max=102400 inactive=20s;
這個將為打開文件指定緩存，默認是沒有啟用的，max指定緩存數量，建議和打開
文件數一致，inactive是指經過多長時間文件沒被請求後刪除緩存。
open_file_cache_valid 30s;
這個是指多長時間檢查一次緩存的有效信息。
open_file_cache_min_uses 1;
open_file_cache指令中的inactive參數時間內文件的最少使用次數，如果超過這
個數字，文件描述符一直是在緩存中打開的，如上例，如果有一個文件在inactive
時間內一次沒被使用，它將被移除。
2) Linux內核參數優化：
net.ipv4.tcp_max_tw_buckets = 10000
timewait的數量，默認是180000。
net.ipv4.ip_local_port_range = 1024 65000
允許系統打開的端口範圍。
net.ipv4.tcp_tw_recycle = 1
啟用timewait快速回收。
net.ipv4.tcp_tw_reuse = 1
開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連接。
net.ipv4.tcp_syncookies = 1
開啟SYN Cookies，當出現SYN等待隊列溢出時，啟用cookies來處理。
Nginx常用配置參數有upstream，主要用於均衡後端多個實例：
Nginx 的upstream目前支持5種算法分配方式：
1) 輪詢（默認rr）
每個請求按時間順序逐一分配到後端不同的服務器，如果後端某臺服務器down掉，自動剔除，待恢復自動添加上。
2) Weight權重
指定輪詢權重，權重越高，處理的請求就越多，weight和訪問比率成正比，用於後端服務器性能不均的情況。
3) ip_hash
每個請求根據訪問的IP的hash結果分配，這樣每個訪客固定訪問一個後端服務器，可以解決session的問題，一般用於登錄會話。
4) fair（第三方）
按後端服務器的響應時間來分配請求，響應時間短的優先分配。
5) url_hash（第三方）
upstream的 fail_timeout和max_fails參數是用來判斷負載均衡upstream中的某個server是否失效。
在fail_timeout的時間內，nignx與upstream中某個server的連接嘗試失敗了max_fails次，則nginx會認為該server已經失效。在接下來的 fail_timeout時間內，nginx不再將請求分發給失效的server。
例如在nginx.conf裏面配置如下的tdt_app均衡：
upstream tdt_app {
server 10.10.1.11:8080 weight=1 max_fails=2 fail_timeout=30s;
server 10.10.1.12:8080 weight=1 max_fails=2 fail_timeout=30s;
}
Tdt_app均衡兩臺後端JAVA服務，在30秒內nginx會與後端的某個server通信檢測，如果檢測連接失敗2次，則Nginx會認為該server已經失效，然後踢出轉發列表，然後在接下來的30s內，nginx不再講請求轉發給失效的server。
另外，fail_timeout設置的時間對響應時間沒影響，這個響應時間是用proxy_connect_timeout和proxy_read_timeout來控制的。
proxy_connect_timeout : Nginx與後端服務器連接的超時時間，發起握手等候響應超時時間。
proxy_read_timeout：連接成功後_等候後端服務器響應時間，其實已經進入後端的排隊之中等候處理（也可以說是後端服務器處理請求的時間）。
proxy_send_timeout :後端服務器數據回傳時間，在規定時間之內後端服務器必須傳完所有的數據。
keepalive_timout：一個http產生的tcp連接在傳送完最後一個響應後，還需要等待多少秒後，才關閉這個連接。
Nginx配置優化及深入講解,大家可以聽一下