nginx優化_性能方面的優化
1.3 Nginx性能優化
1.3.1 優化nginx worker進行個數
nginx服務主要有兩個重要進程：
01） master進程：可以控制nginx服務的啟動 停止 或重啟
02） worker進程：處理用戶請求信息，幫助用戶向後端服務進行請求（php mysql）
添加worker進程方法
vim nginx.conf
worker_processes 1; # 修改nginx配置文件中worker_processes指令後面的數值
建議：worker進程數量=等於CPU的核數 worker進程數量=等於CPU的核數*2
如何在一個系統中獲悉CPU核心是多少？
①. 利用top命令--按數字1，獲取到CPU核數信息
②. grep processor /proc/cpuinfo|wc -l
③. lscpu
查看cpu核心數命令示例
示例一
[root@web01 ~]# top # 按數字1
top - 03:22:48 up 9 days, 26 min, 4 users, load average: 1.06, 0.99, 0.92
Tasks: 107 total, 1 running, 106 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.2%us, 0.6%sy, 0.0%ni, 99.0%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 0.1%us, 0.1%sy, 0.0%ni, 99.1%id, 0.7%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 485984k total, 452536k used, 33448k free, 24984k buffers
Swap: 786428k total, 5912k used, 780516k free, 242048k cached
示例二
[root@web01 ~]# lscpu |grep CPU
CPU op-mode(s): 32-bit, 64-bit
CPU(s): 2
示例三
[root@web01 ~]# grep processor /proc/cpuinfo
processor : 0
processor : 1
1.3.2 綁定不同的nginx進程到不同的CPU上
4個worker進程分配CPU資源方法：
worker_processes 4；
worker_cpu_affinity 0001 0010 0100 1000；
8個worker進程分配CPU資源方法;
worker_processes 8；
worker_cpu_affinity 0001 0010 0100 1000 0001 0010 0100 1000； # 分配8進程方法
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000；
4個worker進程分配CPU資源方法：
worker_processes 4；
worker_cpu_affinity 0101 1010； # 將進程分配到兩顆CPU上
1.3.3 優化nginx事件處理模型
官方配置參數說明：http://nginx.org/en/docs/ngx_core_module.html#use
Syntax: use method;
Default: —
Context: events
關於事件處理模型可以參考：https://clsn.cnblogs.com/p/7750615.html#auto_id_10
舉例配置：
user www www;
worker_processes 1;
events {
worker_connections 1024;
use epoll; --- 指定使用的模型為epoll
}
1.3.4 調整nginx單個進程允許的客戶端最大連接數
查看nginx當前的打開文件數
[root@clsn ~]# lsof -i:80
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nginx 10422 root 6u IPv4 11868856 0t0 TCP *:http (LISTEN)
nginx 10424 www 6u IPv4 11868856 0t0 TCP *:http (LISTEN)
nginx 10425 www 6u IPv4 11868856 0t0 TCP *:http
修改最大連接數方法
vim nginx.conf
events #<==events指令是設定Nginx的工作模式及連接數上限
{
worker_connections 1024；
}
說 明：此數值設置不要超過系統最大打開文件數量。
1.3.5 配置Nginx worker進程最大打開文件數
舉例配置：
[root@web02 conf]# cat nginx.conf
user www www;
worker_processes 1;
worker_rlimit_nofile 2048; # 設置worker進程打開文件數
1.3.6 優化nginx高效文件傳輸模式
sendfile參數的官方說明如下：
syntax：sendfile on | off; #<==參數語法
default：sendfile off; #<==參數默認大小
context：http，server，location，if in location #<==可以放置的標簽段
說明：在系統內核中，利用零拷貝方式實現數據傳輸
實現高效數據傳輸的兩種方式
第一種方式：tcp_nopush
syntax： tcp_nopush on | off; #<==參數語法
default： tcp_nopush off; #<==參數默認大小
context： http，server，location #<==可以放置的標簽段
說明：將數據包積攢到一定量時再進行傳輸
參數作用：
激活或禁用Linux上的TCP_NODELAY選項。這個參數啟用只在連接傳輸進入到 keep-alive狀態。TCP_NODELAY和TCP_CORK基本上控制了包的"Nagle化"，Nagle化在這裏 的含義是采用Nagle算法把較小的包組裝為更大的幀。John Nagle是Nagle算法的發明人，後者就是用他的名字來命名的。
此算法解決的問題就是所謂的silly window syndrome,中文稱"愚蠢窗口癥候群"，具體含義是，因為普遍終端應用程序每產生一次擊鍵操作就會發送一個包，很輕易地就能令網絡發生擁塞，Nagle化後來成了一種標準並且立即在因特網上得以實現。它現在已經成為缺省配置了，但在我們看來，有些場合下希望發送小塊數據，把這一選項關掉也是合乎需要的。
第二種方式：tcp_nodelay
Syntax: tcp_nodelay on | off;
Default: tcp_nodelay on;
Context: http, server, location
說明：只要有數據包產生，不管大小多少，就盡快傳輸
參數作用：
激活或禁用Linux上的TCP_CORK socket選項，tcp_cork是linux下tcp/ip傳輸的一個標準了，這個標準的大概的意思是，一般情況下，在tcp交互的過程中，當應用程序接收到數據包後馬上傳送出去，不等待，而tcp_cork選項是數據包不會馬上傳送出去，等到數據包最大時，一次性的傳輸出去，這樣有助於解決網絡堵塞，已經是默認了。
此選項僅僅當開啟sendfile時才生效， 激活這個.tcp_nopush參數可以允許把http response header和響應數據文件的開始部分放在一個文件裏發布，其積極的作用是減少網絡報文段的數量。
強調：兩個指令是相悖的，請選擇其一開啟，不要同時開啟;
默認采用tcp_nodelay方式進行傳輸。
1.3.7 設置nginx服務超時參數
Nginx連接超時的參數設置
1) 設置參數： keepalive_timeout 60; # 長連接才有意義
keepalive_timeout參數的官方說明如下：
syntax：keepalive_timeout timeout [header_timeout];#<==參數語法
default：keepalive_timeout 75s;#<==參數默認大小
context：http，server，location #<==可以放置的標簽段
說明：客戶端和服務端都沒有數據傳輸時，進行超時時間倒計時，一旦超時時間讀取完畢還沒有數據傳輸，就斷開連接
2) 設置參數：client_header_timeout 55;
syntax：client_header_timeout time; #<==參數語法
default：client_header_timeout 60s; #<==參數默認大小
context：http，server #<==可以放置的標簽段
說明：表示定義客戶端請求報文發送的間隔超時時間，客戶端發送的請求報文中請求頭信息的間隔時間
3）設置參數：client_body_timeout 55;
syntax：client_body_timeout time; #<==參數語法
default：client_body_timeout 60s; #<==默認值是60秒
context：http，server，location #<==可以放置的標簽段
說明：表示定義服務端響應報文發送的間隔超時時間，客戶端發送的請求報文中請求主體信息的間隔時間
4）設置參數：send_timeout 60s
syntax：send_timeout time; #<==參數語法
default：send_timeout 60s; #<==默認值是60秒
context：http，server，location #<==可以放置的標簽段
說明：表示定義客戶端讀取服務端響應報文的間隔超時時間，服務端發送的響應報文間隔時間
1.3.8 配置Nginx gzip壓縮實現性能優化
1. Nginx gzip壓縮功能介紹
Nginx gzip壓縮模塊提供了壓縮文件內容的功能，用戶請求的內容在發送到用戶客戶端之前， Nginx服務器會根據一些具體的策略實施壓縮，以節約網站出口帶寬，同時加快數據傳輸效率，來提升用戶訪問體驗。
2. Nginx gzip壓縮的優點
提升網站用戶體驗：
發送給用戶的內容小了，用戶訪問單位大小的頁面就加快了，用戶體驗提升了，網站口碑就好了。
節約網站帶寬成本：
數據是壓縮傳輸的，因此節省了網站的帶寬流量成本，不過壓縮時會稍 微消耗一些CPU資源，這個一般可以忽略。
此功能既能提升用戶體驗，又能使公司少花錢，一舉多得。對於幾乎所有的Web服務來說，這 是一個非常重要的功能，Apache服務也有此功能。
官方用法參考鏈接：http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip
gzip on;
gzip_min_length 1k;
gzip_buffers 4 16k;
gzip_http_version 1.1;
gzip_comp_level 4;
gzip_types text/css text/xml application/javascript;
gzip_vary on;
說明：將服務端響應的數據信息進行壓縮，可以有效節省帶寬，提高用戶訪問效率
需要和不需要壓縮的對象
- 1. 純文本內容壓縮比很高，因此，純文本的內容最好進行壓縮，例如：html、js、css、xml、shtml等格式的文件。
- 2. 被壓縮的純文本文件必須要大於1KB，由於壓縮算法的特殊原因，極小的文件壓縮後可能反而變大。
- 3. 圖片、視頻（流媒體）等文件盡量不要壓縮，因為這些文件大多都是經過壓縮的。
- 4. 如果再壓縮很可能不會減小或減小很少，或者有可能增大，同時壓縮時還會消耗大量的CPU、內存資源。
壓縮配置參數說明
gzip on ;
#<==開啟gzip壓縮功能。
gzip_min_length lk;
#<==設置允許壓縮的頁面最小宇節數，頁面宇節數從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壓縮的數據。
1.3.9 配置Nginx expires緩存實現性能優化
簡單地說，Nginx expires的功能就是為用戶訪問的網站內容設定一個過期時間，當用戶第一次訪問這些內容時，會把這些內容存儲在用戶瀏覽器本地，這樣用戶第二次及以後繼續訪問該網站時，瀏覽器會檢查加載已經緩存在用戶瀏覽器本地的內容，就不會去服務器下載了，直到緩存的內容過期或被清除為止。
Nginx expires功能優點
- 1. expires可以降低網站的帶寬，節約成本。
- 2. 加快用戶訪問網站的速度，提升用戶訪問體驗。
- 3. 服務器訪問量降低了，服務器壓力就減輕了，服務器成本也會降低，甚至可以節約人力成本。
- 4. 對於幾乎所有的Web服務來說，這是非常重要的功能之一，Apache服務也有此功能。
實踐配置
[root@web02 extra]# cat blog.conf
server {
listen 80;
server_name blog.etiantian.org;
server_tokens off;
# 靜態請求處理的location
location / {
root html/blog;
index index.php index.html index.htm;
}
# 動態請求處理的location
location ~* .*\.(php|php5)?$ {
root html/blog;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi.conf;
}
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$
{
expires 10y;
root html/blog;
}
location ~ .*\.(js|css)$
{
expires 30d;
root html/blog;
}
}
location / {
expires 3650d;
}
企業網站有可能不希望被緩存的內容
- 1. 廣告圖片，用於廣告服務，都緩存了就不好控制展示了。
- 2. 網站流量統計工具（JS代碼），都緩存了流量統計就不準了。
- 3. 更新很頻繁的文件（google的logo），這個如果按天，緩存效果還是顯著的。
1.3.10 配置FastCGI優化
FastCGI Cache資料見:
http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_cache
FastCGI常見參數的Nginx配置示例如下:
[root@nginx conf]# cat nginx.conf
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
worker_rlimit_nofile 65535;
user nginx;
events {
use epoll;
worker_connections 10240;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
tcp_nopush on;
keepalive_timeout 65;
tcp_nodelay on;
client_header_timeout 15;
client_body_timeout 15;
send_timeout 15;
log_format main ‘$remote_addr - $remote_user [$time_local] "$request" ‘
‘$status $body_bytes_sent "$http_referer" ‘
‘"$http_user_agent" "$http_x_forwarded_for"‘;
server_tokens off;
fastcgi_connect_timeout 240;
fastcgi_send_timeout 240;
fastcgi_read_timeout 240;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
#fastcgi_temp_path /data/ngx_fcgi_tmp;
fastcgi_cache_path /data/ngx_fcgi_cache levels=2:2 keys_zone=ngx_fcgi_cache:512m inactive=1d max_size=40g;
#web...............
server {
listen 80;
server_name blog.nmtui.com;
root html/blog;
location / {
root html/blog;
index index.php index.html index.htm;
}
location ~ .*\.（php|php5）${
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi.conf;
fastcgi_cache ngx_fcgi_cache;
fastcgi_cache_valid 200 302 1h;
fastcgi_cache_valid 301 1d;
fastcgi_cache_valid any 1m;
fastcgi_cache_min_uses 1;
fastcgi_cache_use_stale error timeout invalid_header http_500;
fastcgi_cache_key http://$host$request_uri;
}
access_log logs/web_blog_access.log main;
}
upstream blog_etiantian{
server 10.0.0.8:8000 weight=1;
}
server {
listen 8000;
server_name blog.nmtui.com;
location / {
proxy_pass http://blog_etiantian;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $remote_addr;
}
access_log logs/proxy_blog_access.log main;
}
}
FastCGI常見參數列表說明：
|
Nginx FastCGI 相關參數 |
說明 |
|
fastcgi_connect_timeout |
表示nginx服務器和後端FastCGI服務器連接的超時時間，默認值為60秒，這個參數值通常不要超過75秒，因為建立的連接越多，消耗的資源就越多 |
|
fastcgi_send_timeout |
設置nginx傳輸請求到FastCGI服務器的超時時間，這個超時時間不是整個請求的超時時間，而是兩個成功請求的之間間隔時間為超時時間，如果這個時間內，FastCGI服務沒有收到任何信息，連接將關閉 |
|
fastcgi_read_timeout |
設置nginx從FastCGI服務器讀取響應信息的超時時間苯示連捿建立成功後， nginx等待後端服務器的響應時間，是nginx進入後端的排隊之中的等候處理的時間，實際上是讀取FastCGI響應成功信息的間隔時間， |
|
fastcgi_buffer_size |
這是Nginx FastCGI的緩沖區大小參數，設定用來讀取從FastCGI服務器端收到的第一部分響應信息的緩沖區大小，這裏的第一部分通常會包含一個小的響應頭部s默認情況下，這個參數的大小等價於_個內存頁。不是4k就是8k 根據相應系統平臺來決定，也可以更小。 |
|
fastcgi_buffers |
設定用來讀取從FastCGI服務器端收到的響應信息的緩沖區大小和緩沖區數是，默認值為fastcgi_buffer 8 4k|8k; 指定本地需要用多少和多大的緩沖區來緩沖FastCGI的應答請求，如果一個 PHP腳本產生的頁面大小為256KB ,那麽會為其分配4個64KB的緩沖區來緩存；如果頁面大小大於256KB ,那麽大於256KB的部分會緩存到fastcgi_temp 指定的路徑中，但是這並不是好方法，因為內存中的數據處理速度要快於硬盤。一般這個值應該為站點中PHP腳本產生的頁面大小的中間值，如果站點大部分腳本所產生的頁面大小為256KB ,那麽可以把這個值設置為"16 16k" , "4 64k"等 |
|
fastcgi_busy_buffers_size |
用於設置系統很忙時可以使用的fastcgi_buffers大小，言方推薦的大小為fastcgi_buffers*2 ;默認值為 fastcgi_busy_buffers_size 8k|16k |
|
fastcgi_temp_file_write_size |
FastCGI臨時文件的大小，可以設置為128~256KB ; 默認fastcgi_temp_file_write_size 8k|16k; |
|
fastcgi_cache oldboy_nginx |
表示開後FastCGI緩存並為其指定一個名稱。開後緩存非常有用，可以有效降低CPU的負載，並且防止502錯誤的發生，但是開後緩存也可能引起其它問題，要根據具體情況來選擇 |
|
fastcgi_cache_path |
實例：fastcgi_cache_path /data/nginx/cache levels = 2:2 keys_zone = ngx_fcgi_cache:512m inactive = ld max_size=40g; fastcgi_cache緩存目錄，可以設置目錄前列層級，比如2:2會生成256*256 個子目錄，keys_zone是這個緩存空間的名字，cache是用多少內存（這樣熱門的內容，nginx會直接放入內存，提高訪問速度）。inactive表示默認失效時間，max_size表示最多用多少硬盤空間，雲要註意的是fastcgi_cache緩存是先寫在fastcgi_temp_path在移到fastcgi_cache_path中去的，所以這個兩個目錄最好在同一個分區，從0.8.9之後可以在不同的分區，不過還是建議放在同_分區。 |
|
fastcgi_cache_valid |
示例：fastcgi_cache_valid 200 302 lh; 用來指定應答代碼的緩存時間，實例中的值表示將200和302應答緩存1個小時； 示例：fastcgi_cache_valid 301 Id; 將301應答緩存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 requestmethod://hostrequesturi;fastcgi.cache.keyhttp://host$request_uri; 定義fastcgi_cache的key ,示例中以請求的URI作為緩存的key，nginx會取這個key的md5作為緩存文件，如果設置了緩存散列目錄，nginx會從後往前取梠應的位數作為目錄。註意一定要加作為cache key,否則如果先請求的為head 類型，後面的GET清求返回為空。 |
1.4 日誌方面優化
1.4.1 配置Nginx服務相關日誌操作
01. 進行日誌的切割
[root@clsn ~]# mkdir /server/scripts/ -p
[root@clsn ~]# cd /server/scripts/
[root@clsn scripts]# vim cut_nginx_log.sh
#!/bin/bash
cd /application/nginx/logs &&\
/bin/mv www_access.log www_access_$（date +%F -d -1day）.log #<==將日誌按日期改成前一天的名稱
/application/nginx/sbin/nginx -s reload #<==重新加載nginx使得觸發重新生成訪問日誌文件
提示：實際上腳本的功能很簡單，就是改名日誌，然後加載nginx，重新生成文件記錄日誌
說明：也可以編輯使用logrotate日誌切割服務，進行日誌切割
02. 進行日誌的選擇記錄
location ~ .*\.（js|jpg|JPG|jpeg|JPEG|css|bmp|gif|GIF）$ {
access_log off;
}
03. 進行日誌文件授權
假如日誌目錄為/app/logs，則授權方法如下：
chown -R root.root /app/logs
chmod -R 700 /app/logs
04. 日誌信息盡量匯總備份
[root@clsn ~]# zgrep 456 clsn.tar.gz
1.4.2 查看軟件編譯時的參數
①. 查看nginx安裝時編譯了哪些參數
/application/nginx/sbin/nginx -V
②. 查看apache安裝時編譯了哪些參數
cat /application/apache/build/config.nice
/application/apache/bin/apachectl -V #<--也可查看安裝時編譯信息，但顯示的不全
③. 查看mysql安裝時編譯了哪些參數
grep CONFIGURE_LINE /application/mysql/bin/mysqlbug
PS：mysql二進制包的安裝方式，是無法看到編譯參數的，默認為空
④. 查看php安裝時編譯了哪些參數
/application/php/bin/php -i|grep configure
nginx優化_性能方面的優化