優化Nginx服務的worker進程個數
修改nginx主配置文件
worker_processes 1; #指定了Nginx要開啟的進程數，結尾數字就是進程個數
Nginx有Master進程和worker進程之分，Master為管理進程，真正接待“顧客”的是worker進程。
優化Nginx進程個數的策略
(1)worker_processes參數大小的設置最好和網站的用戶數量相關聯，
(2)新搭建服務器時，worker進程數最開始的設置可以等於CPU的核數,高流量高並發場合也可以考慮將進程數提高至CPU核數*2
查看Web服務器CPU硬件資源信息
通過/proc/cpuinfo可查看CPU個數及總核數。查看CPU總核數的示例如下:
grep processor /proc/cpuinfo processor : 0 processor : 1 processor : 2 processor : 3 grep processor /proc/cpuinfo | wc -l 4 #表示為1顆CPU四核
#查看CPU總顆數示例如下： grep "physical id" /proc/cpuinfo physical id : 0 #物理ID一致，同一顆CPU physical id : 0 #物理ID一致，同一顆CPU physical id : 0 #物理ID一致，同一顆CPU physical id : 0 #物理ID一致，同一顆CPU grep "physical id" /proc/cpuinfo | sort | uniq | wc -l 1 #去重復，表示1顆CPU
修改重啟后的worker進程數量，如下：
ps -ef | grep "nginx" | grep -v grep root 1110 1 0 11:12 ? 00:00:00 nginx: master process /usr/local/nginx/sbin/nginx nginx 1429 1110 0 11:33 ? 00:00:00 nginx: worker process nginx 1430 1110 0 11:33 ? 00:00:00 nginx: worker process nginx 1431 1110 0 11:33 ? 00:00:00 nginx: worker process nginx 1432 1110 0 11:33 ? 00:00:00 nginx: worker process
從“worker_processes 4”可知，worker進程數為4個。Nginx Master主進程不包含在這個參數內，Nginx Master的主進程為管理進程，負責調度和管理worker進程。
Nginx事件處理模型優化
在Linux下，Nginx使用epoll的I/O多路復用模型，在Freebsd中使用kqueue的I/O多路復用模型，在Solaris中使用/dev/poll方式的I/O多路復用模型，在Windows中使用的是icop，等等。
也可以不指定事件處理模型，Nginx會自動選擇最佳的事件處理模型服務。
#具體的配置參數如下： events #events指令是設定Nginx的工作模式及連接數上限 { use epoll； #use是一個事件模塊指令，用來指定Nginx的工作模式。Nginx支持的工作模式有select，poll，kqueue，epoll，rtsig和/dev/poll。
其中select和poll都是標准的工作模式，kqueue和epoll是高效的工作模式，不同的是epoll用在Linux平台上，而kqueue用在BSD系統中。
對於Linux系統Linux2.6+內核，推薦選擇epoll工作模式，這是高性能高並發的設置 }
調整Nginx單個進程允許的客戶端最大連接數
調整Nginx單個進程允許的客戶端最大連接數,控制參數為work_connections。 (worker_connections的值要根據具體服務器性能和程序的內存使用量來指定)
events #events指令是設定Nginx的工作模式和連接數上線 { worker_connections 20480; #worker_connections也是個事件模塊指令，用於定義Nginx每個進程的最大連接數，默認是1024.最大客戶端連接數由worker_processes和worker_connections決定，
即Max_client= worker_processes*worker_connections。進程的最大連接數受Linux系統進程的最大打開文件數限制，在執行操作系統命令
“ulimit -HSn 65535”或配置相應文件后，worker_connections的設置才能生效。 }
實際的並發連接數除了受worker_connections參數控制外，還和最大打開文件數worker_rlimit_nofile有關，Nginx總並發連接=worker數量*worker_connections。
配置Nginx worker進程最大打開文件數
worker_rlimit_nofile 65535; #最大打開文件數，可設置為系統優化后的ulimit -HSn的結果
放置位置：主標簽段 此參數的作用是改變worker processes能打開的最大文件數
開啟高效文件傳輸模式
http模塊
設置參數1：sendfile on; #激活或禁用sendfile()功能功能。
#sendfile參數用於開啟文件的高效傳輸模式。同時將tcp_nopush和tcp_nodelay兩個指令設置為on，可防止網絡及磁盤I/O阻塞，提升Nginx工作效率。
設置參數2：tcp_nopush on; #激活或禁用Linux上的TCP_CORK socket選項，此選項僅僅當開啟sendfile時才生效,允許把http response header和文件的開始部分放在一個文件里發布，作用是減少網絡報文段的數量。
優化Nginx連接參數，調整連接超時時間
連接超時的作用
(1)將無用的連接設置為盡快超時，可以保護服務器的系統資源
(2)當連接很多時，及時斷掉那些已經建立好的但又長時間不做事的連接，以減少其占用的服務器資源
(3)黑客攻擊網站，就會不斷地和服務器建立多個連接，消耗連接數，大量消耗服務器的資源.
(4)LNMP環境中，如果用戶請求了動態服務，則Nginx就會建立連接，請求FastCGI服務以及后端MySQL服務,，后端的FastCGI服務及MySQL服務也有對連接的超時控制。
不同程序連接設定知識
服務器建立新連接也是要消耗資源的，因此，超時設置得太短而並發很大，就會導致服務器瞬間無法響應用戶的請求，導致用戶體驗下降。
PHP程序站點設置成短連接，PHP程序建立連接消耗的資源和時間相對要少些。對於Java程序站點來說，一般建議設置長連接，因為Java程序建立連接消耗的資源和時間更多.
Nginx連接超時的參數設置
在http模塊
設置參數(1)：keepalive_timeout 60; #保持會話的超時時間為60秒
設置參數(2)：tcp_nodelay on; #用於激活tcp_ondelay功能，提高I/O性能。
默認情況下當數據發送時，內核並不會馬上發送，可能會等待更多的字節組成一個數據包，這樣可以提高I/O性能。使用tcp_nodelay功能，等待時間會比較長。
設置參數(3)：client_header_timeout 15; #設置讀取客戶端請求頭數據的超時時間
設置讀取客戶端請求頭數據的超時時間。服務器端將返回“Request time out (408)”錯誤，可指定一個超時時間，防止客戶端利用http協議進行攻擊。
設置參數(4)：client_body_timeout 15; #用於設置讀取客戶端請求主體的超時時間，默認值60
設置參數(5)：send_timeout 25; #用於指定響應客戶端的超時時間。
上傳文件大小的限制
調整上傳文件的大小
在Nginx主配置文件里加入如下參數：
client_max_body_size 8m; #具體大小根據公司的業務做調整，如果不清楚就先設置為8m.
設置最大的允許的客戶端請求主體大小，在請求頭域有“Content-Length”，如果超過了此配置值，客戶端會受到413錯誤，設置為0表示禁止檢查客戶端請求主體大小。
FastCGI相關參數調優
Nginx FastCGI客戶端向后請求PHP動態引擎服務（php-fpm（FastCGI服務器端）
fastcgi_connect_timeout ; #表示Nginx服務器和后端FastCGl服務器連接的超時時間，默認值為60fastcgi_ connect. timeout 秒，這個參數值通常不要超過75秒，因為建立的連接越多，消耗的資源就越多
fastcgi_send_timeout ; #設置Nginx允許FastCG1服務器端返回數據的超時時間，即在規定時間之fastcgi_ send. timeout 內后端服務器必須傳完所有的數據，否則，Nginx將斷開這個連接。其默認值為60秒
fastcgi_read_timeout ; #設置Nginx從FastCGl服務器端讀取響應信息的超時時間，表示連接建立fastcgi_ read_ timeout 成功后，Nginx等待后嶺服務器的響應時間，是Nginx已經進人后端的排隊之中等候處理的時間
fastcgi_buffer_size 64k; #這是Nginx FastCGl的緩沖區大小參數，設定用來讀取以FastCGl服務器端收到的第-一部分響應信息的緩沖區大小，這里的第-部分通常會包含-一個fastcgi_ buffer. size小的響應頭部。默認情況下，這個參數的大小是由fastegi buffers 指定的一個緩沖區的大小
fastcgi_buffers 4 64k; #設定用來讀取從FastCGl服務器端收到的響應信息的緩沖區大小和緩沖區數量，默認值為fastcgi buffers 8 4k{8k;。指定本地需要用多少和多大的緩沖區來緩沖FastCGl的應答請求。如果一個PHP腳本所產生的頁面大小為256KB，那么會為其分配4個64KB的緩fastcgi_ buffers 沖區來緩存;如果頁面大小大於256KB.那么大於256KB的部分會緩存到fastcgi temp 指定的路徑中，但是這並不是好方法，因為內存中的數據處理速度要快於硬盤。一般這個值應該為站點中PHP腳本所產生的頁面大小的中間值，如果站點大部分腳本所產生的頁面大小為256KB,那么可以把這個值設置為“1616k”, "464k”等
proxy_busy_buffers_size ; #用於設置系統很忙時可以使用的proxy_ buffers大小，官方推薦的大小為proxy_ buffers*2
fastcgi_busy_buffers_size ; #用於設置系統很忙時可以使用的fastcgibuffers大小，官方推薦的大小為fastcgi_ buffers*2
fastcgi_temp_file_write_size ; #FastCGI臨時文件的大小,可設為128~256KB
fastcgi_cache_valid ; #示例: fastcgi cache_ valid 200 302 1h;用來指定應答代碼的緩存時間，實例中的值表示將200和302應答緩存一個小時。示例: fastcgi_ cache_ valid 301 ld;將301應答緩存1天。示例: fastcgi_ cache_ valid any 1m,將其他應答緩存設置為1分鍾
fastcgi_ cache_ min_ uses; #示例: fastcgi_ cache_ min_ uses 1;設置請求幾次之后響應將被緩存，1表示一次即被緩存
fastcgi_ cache_ use_ stale; # 示例: fastcgi_ cache_ use_ stale error timeout invalid_ header http_ 500;定義在哪些情況下使用過期緩存
fastcgi_ cache_ key; #示例: fastcgi_ cache_ key $request_ method://$host$request_ uri;fastcgi_ cache_ key http://$host$request uri;定義fastcgi cache的key,示例中以請求的URI作為緩存的key, Nginxfastcgi_ cache_ key 會取這個key的md5作為緩存文件，如果設置了緩存散列目錄，Nginx會從后往前取相應的位數做為目錄。注意一定要加上$request_ method 作為cache key, 否則如果先請求的為head類型，后面的GET請求返回為空
Nginx gzip壓縮實現性能優化
Nginx gzip壓縮功能介紹
Nginx gzip壓縮模塊提供了壓縮文件內容的功能,Nginx服務器會根據一些具體的策略實施壓縮，以節約網站出口帶寬，同時加快數據傳輸效率，來提升用戶訪問體驗。
Nginx gzip壓縮的優點
(1)提升網站用戶體驗;發送給用戶的內容小了，用戶訪問單位大小的頁面就加快了，用戶體驗提升了
(2)節約網站帶寬成本：數據是壓縮傳輸的，因此節省了網站的帶寬流量成本，不過壓縮時會稍微消耗一些CPU資源，這個一般可以忽略。
#此功能既能提升用戶體驗，又能使公司少花錢，一舉多得。對於幾乎所有的Web服務來說，這是一個非常重要的功能，Apache服務也有此功能。
需要和不需要壓縮的對象
純文本內容壓縮比很高，純文本的內容最好進行壓縮，例如：html，js，css，xml，shtml等格式的文件。
被壓縮的純文本文件必須要大於1KB.
圖片，視頻（流媒體）等文件盡量不要壓縮，因為這些文件大多都是經過壓縮的.
參數介紹及配置說明
Nginx的gzip壓縮功能依賴於ngx_http_gzip_module模塊，默認已安裝。
對應的壓縮參數說明如下：
#######壓縮的配置介紹###### gzip on； #開啟gzip壓縮功能 gzip_min_length 1k; #設置允許壓縮的頁面最小字節數，頁面字節數從header頭的Content-Length中獲取。默認值0，表示不管頁面多大都進行壓縮。 建議設置成大於1K，如果小於1K可能會越壓越大。 gzip_buffers 4 16K; #壓縮緩沖區大小。表示申請4個單位為16K的內存作為壓縮結果流緩存，默認值是申請與原始數據大小相同的內存空間來存儲gzip壓縮結果。 gzip_http_version 1.1; #壓縮版本（默認1.1，前端為squid2.5時使用1.0），用於設置識別HTTP協議版本，默認是1.1，目前大部分瀏覽器已經支持GZIP解壓， 使用默認即可。 gzip_comp_level 2; #壓縮比率。用來指定gzip壓縮比，1壓縮比最小，處理速度最快；9壓縮比最大，傳輸速度快，但處理最慢，也比較消耗CPU資源。 gzip_types text/plain application/x-javascript text/css application/xml; #用來指定壓縮的類型，“text/html”類型總是會被壓縮，這個就是HTTP原理部分講的媒體類型。 gzip_vary on; #vary header支持。該選項可以讓前端的緩存服務器緩存經過gzip壓縮的頁面，例如用Squid緩存經過Nginx壓縮的數據。
配置Nginx expires緩存實現性能優化
Nginx expires功能介紹
簡單說，Nginx expires的功能就是為用戶訪問的網站內容設定一個過期時間，當用戶第一次訪問這些內容時，會把這些內容存儲在用戶瀏覽器本地，這樣用戶第二次及以后繼續訪問該網站時，瀏覽器會檢查加載已經緩存在用戶瀏覽器本地的內容，就不會去服務器下載了，直到緩存的內容過期或被清除為止。
Nginx expires功能優點
- expires可以降低網站的帶寬，節約成本。
- 加快用戶訪問網站的速度，提升用戶訪問體驗。
- 服務器訪問量降低了，服務器壓力就減輕了，服務器成本也會降低，甚至可以節約人力成本。
- 對於幾乎所有的Web服務來說，這是非常重要的功能之一，Apache服務也有此功能。
Nginx expires配置詳解
根據文件擴展名進行判斷，添加expires功能范例:
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
{
expires 3650d; #緩存時間3650天
}
location ~ .*\.(js|css)$
{
expires 30d;
}
}
根據URL中的路徑（目錄）進行判斷，添加expires功能范例:
location ~ ^/(images|javascript|js|css|flash|media|static)/
{
expires 360d;
}
當網站被緩存的頁面或數據更新了，此時用戶端看到的可能還是舊的已經緩存的內容，這樣就會影響用戶體驗，那么如何解決這個問題呢？
對於經常需要變動的圖片等文件，可以縮短對象緩存時間
當網站改版或更新時，可以在服務器將緩存的對象改名
企業網站緩存日期曾經的案例參考
- 新浪：15天
- 京東：25年
- 淘寶：10年
企業網站有可能不希望被緩存的內容
- 廣告圖片，用於廣告服務，都緩存了就不好控制展示了。
- 網站流量統計工具（JS代碼），都緩存了流量統計就不准了。
- 更新很頻繁的文件（google的logo），這個如果按天，緩存效果還是顯著的。