nginx作為高性能web服務器，即使不特意調整配置參數也可以處理大量的並發請求。
以下的配置參數是借鑒網上的一些調優參數，僅作為參考，不見得適於你的線上業務。
worker進程
- worker_processes
該參數表示啟動幾個工作進程，建議和本機CPU核數保持一致，每一核CPU處理一個進程。
- worker_rlimit_nofile
它表示Nginx最大可用的文件描述符個數，需要配合系統的最大描述符，建議設置為102400。
還需要在系統里執行ulimit -n 102400才可以。
也可以直接修改配置文件/etc/security/limits.conf修改
增加：
* soft nofile 655350
* hard nofile 655350
- worker_connections
該參數用來配置每個Nginx worker進程最大處理的連接數，這個參數也決定了該Nginx服務器最多能處理多少客戶端請求
（worker_processes * worker_connections)，建議把該參數設置為10240，不建議太大。
http和tcp連接
- use epoll
使用epoll模式的事件驅動模型，該模型為Linux系統下最優方式。
- multi_accept on
使每個worker進程可以同時處理多個客戶端請求。
- sendfile on
使用內核的FD文件傳輸功能，可以減少user mode和kernel mode的切換，從而提升服務器性能。
- tcp_nopush on
當tcp_nopush設置為on時，會調用tcp_cork方法進行數據傳輸。
使用該方法會產生這樣的效果：當應用程序產生數據時，內核不會立馬封裝包，而是當數據量積累到一定量時才會封裝，然后傳輸。
- tcp_nodelay on
不緩存data-sends（關閉 Nagle 算法），這個能夠提高高頻發送小數據報文的實時性。
(關於Nagle算法)
【假如需要頻繁的發送一些小包數據，比如說1個字節，以IPv4為例的話，則每個包都要附帶40字節的頭，
也就是說，總計41個字節的數據里，其中只有1個字節是我們需要的數據。
為了解決這個問題，出現了Nagle算法。
它規定：如果包的大小滿足MSS，那么可以立即發送，否則數據會被放到緩沖區，等到已經發送的包被確認了之后才能繼續發送。
通過這樣的規定，可以降低網絡里小包的數量，從而提升網絡性能。】
- keepalive_timeout
定義長連接的超時時間，建議30s，太短或者太長都不一定合適，當然，最好是根據業務自身的情況來動態地調整該參數。
- keepalive_requests
定義當客戶端和服務端處於長連接的情況下，每個客戶端最多可以請求多少次，可以設置很大，比如50000.
- reset_timeout_connection on
設置為on的話，當客戶端不再向服務端發送請求時，允許服務端關閉該連接。
- client_body_timeout
客戶端如果在該指定時間內沒有加載完body數據，則斷開連接，單位是秒，默認60，可以設置為10。
- send_timeout
這個超時時間是發送響應的超時時間，即Nginx服務器向客戶端發送了數據包，但客戶端一直沒有去接收這個數據包。
如果某個連接超過send_timeout定義的超時時間，那么Nginx將會關閉這個連接。單位是秒，可以設置為3。
buffer和cache(以下配置都是針對單個請求)
- client_body_buffer_size
當客戶端以POST方法提交一些數據到服務端時，會先寫入到client_body_buffer中，如果buffer寫滿會寫到臨時文件里，建議調整為128k。
- client_max_body_size
瀏覽器在發送含有較大HTTP body的請求時，其頭部會有一個Content-Length字段，client_max_body_size是用來限制Content-Length所示值的大小的。
這個限制body的配置不用等Nginx接收完所有的HTTP包體，就可以告訴用戶請求過大不被接受。會返回413狀態碼。
例如，用戶試圖上傳一個1GB的文件，Nginx在收完包頭后，發現Content-Length超過client_max_body_size定義的值，
就直接發送413(Request Entity Too Large)響應給客戶端。
將該數值設置為0，則禁用限制，建議設置為10m。
- client_header_buffer_size
設置客戶端header的buffer大小，建議4k。
- large_client_header_buffers
對於比較大的header（超過client_header_buffer_size）將會使用該部分buffer，兩個數值，第一個是個數，第二個是每個buffer的大小。
建議設置為4 8k
- open_file_cache
該參數會對以下信息進行緩存：
打開文件描述符的文件大小和修改時間信息;
存在的目錄信息;
搜索文件的錯誤信息（文件不存在無權限讀取等信息）。
格式：open_file_cache max=size inactive=time;
max設定緩存文件的數量，inactive設定經過多長時間文件沒被請求后刪除緩存。
建議設置 open_file_cache max=102400 inactive=20s;
- open_file_cache_valid
指多長時間檢查一次緩存的有效信息。建議設置為30s。
- open_file_cache_min_uses
open_file_cache指令中的inactive參數時間內文件的最少使用次數，
如,將該參數設置為1，則表示，如果文件在inactive時間內一次都沒被使用，它將被移除。
建議設置為2。
壓縮
對於純文本的內容，Nginx是可以使用gzip壓縮的。使用壓縮技術可以減少對帶寬的消耗。
由ngx_http_gzip_module模塊支持
配置如下：
gzip on; //開啟gzip功能 gzip_min_length 1024; //設置請求資源超過該數值才進行壓縮，單位字節 gzip_buffers 16 8k; //設置壓縮使用的buffer大小，第一個數字為數量，第二個為每個buffer的大小 gzip_comp_level 6; //設置壓縮級別，范圍1-9,9壓縮級別最高，也最耗費CPU資源 gzip_types text/plain application/x-javascript text/css application/xml image/jpeg image/gif image/png; //指定哪些類型的文件需要壓縮 gzip_disable "MSIE 6\."; //IE6瀏覽器不啟用壓縮
測試：
curl -I -H "Accept-Encoding: gzip, deflate" http://www.aminglinux.com/1.css
日志
- 錯誤日志級別調高，比如crit級別，盡量少記錄無關緊要的日志。
- 對於訪問日志，如果不要求記錄日志，可以關閉，
- 靜態資源的訪問日志關閉
靜態文件過期
對於靜態文件，需要設置一個過期時間，這樣可以讓這些資源緩存到客戶端瀏覽器，
在緩存未失效前，客戶端不再向服務期請求相同的資源，從而節省帶寬和資源消耗。
配置示例如下：
location ~* ^.+\.(gif|jpg|png|css|js)$ { expires 1d; //1d表示1天，也可以用24h表示一天。 }
作為代理服務器
Nginx絕大多數情況下都是作為代理或者負載均衡的角色。 因為其他文章已經介紹過以下參數的含義，在這里只提供對應的配置參數： http { proxy_cache_path /data/nginx_cache/ levels=1:2 keys_zone=my_zone:10m inactive=300s max_size=5g; ...; server { proxy_buffering on; proxy_buffer_size 4k; proxy_buffers 2 4k; proxy_busy_buffers_size 4k; proxy_temp_path /tmp/nginx_proxy_tmp 1 2; proxy_max_temp_file_size 20M; proxy_temp_file_write_size 8k; location / { proxy_cache my_zone; ...; } } }
SSL優化
- 適當減少worker_processes數量，因為ssl功能需要使用CPU的計算。
- 使用長連接，因為每次建立ssl會話，都會耗費一定的資源（加密、解密）
- 開啟ssl緩存，簡化服務端和客戶端的“握手”過程。
ssl_session_cache shared:SSL:10m; //緩存為10M ssl_session_timeout 10m; //會話超時時間為10分鍾