1八、nginx優化

一.性能優化概述

基詢imm能優化,那麼在性能優化這一章,咱們將分爲以下幾個方面作介紹
1.首先咱們須要瞭解性能優化要考慮哪些方面。
2.而後咱們須要瞭解性能優化必需要用到的壓力測試工具ab。
3.最後咱們須要瞭解系統上有哪些注意和優化點,以及Nginx配置文件。javascript

咱們在作性能優化工做前,咱們重點須要考慮哪些方面,和了解哪些方面。
1.首先須要瞭解咱們當前系統結構和瓶頸,瞭解當前使用的是什麼,運行的是什麼業務,都有哪些服務,瞭解每一個服務最大能支撐多大併發。好比Nginx做爲靜態資源服務的併發是多少,最高支持多少qps(每秒查詢率)的訪問請求,那咱們怎麼得出這組系統結構瓶頸呢,比top查看系統負載的CPU、內存使用率、總的運行進程等,也能夠經過曰志去分析請求的狀況,固然也能夠經過咱們前面介紹到stub_status模塊查看當前的鏈接狀況,也能夠對線上的業務進行壓力測試(低峯期),去了解當前這套系統能承擔多少的請求和併發,以作好相應的評估。這個是咱們作性能優化最早考慮的地方。
2.其次咱們須要瞭解業務模式,雖然咱們是作性能優化,但每個性能的優化都是爲業務所提供服務的,咱們須要瞭解每一個業務接口的類型,好比:電商網站中的搶購模式,這種狀況下面,平時沒什麼流量,但到了搶購時間流量會突增。
咱們還須要瞭解系統層次化的結構,好比:咱們使用Nginx作的是代理、仍是動靜分離,仍是後端直接服務用戶,那麼這個就須要咱們對每一層作好相應的梳理,以便更好的服務業務。
3.最後咱們考慮性能與安全,每每注重了性能,可是忽略了安全。每每過於注重安全,性能又會產生影響。好比:咱們在設計防火牆功能時,檢測過於嚴密,這樣就會給性能帶來影響。那麼若是對性能徹底追求,卻不顧服務的安全,這個也會形成很大的隱患,因此須要評估好二者的關係,把握好二者的孰重孰輕。以及總體的相關性,權衡好對應的點。php

總結:
1.系統結構和瓶頸
2.分析,壓力測試工具ab、stub_status
3.瞭解業務模式
4.瞭解系統層次化的結構
5.性能與安全css

OSI[flag]
硬件 代理(CPU) 靜態(磁盤IO) 動態(cpu、內存)
網絡
系統 文件描述符(文件句柄)
應用 服務於服務保持長鏈接 http1.1
服務 靜態資源服務優化html

二.壓力測試工具

在系統業務量沒有增加以前,咱們就要作好相應的準備工做,已防患業務量突增帶來的接口壓力,因此對於接口壓力測試就顯很是重要了。咱們首先要評估好系統壓力,而後使用工具檢測當前系統狀況,是否能知足對應壓力的需求。java

2.1.安裝壓力測試工具

[root@web01 ~]# yum install httpd-tools -yum

2.2.瞭解壓力測試工具的使用方式

[root@web01 ~]# ab -n 200 -c 2 http://127.0.0.1/
-n   總的請求次數
-c   併發請求次數
-k   是否開啓長鏈接

[root@web01 conf.d]# ab
ab: wrong number of arguments
Usage: ab [options] [http[s]://]hostname[:port]/path

2.3.配置Nginx靜態網站和tomcat動態網站環境

[root@web01 conf.d]# cat jsp.conf 
server {
        server_name _;
        listen 80;
        location / {
                root /code;
                try_files $uri @java_page;
        }
        location @java_page{
                proxy_pass http://127.0.0.1:8080;
        }
}

#分別給Nginx準備靜態網站
[root@web01 ~]# cat /code/tt.html
Nginx Ab Load

#重啓nginx
[root@web01 ~]# systemctl restart nginx
#進行壓力測試
[root@web01 conf.d]# ab  -n100000 -c200 http://127.0.0.1/tt.html
[root@web01 conf.d]# ab -k -n100000 -c200 http://127.0.0.1/tt.html

#準備Tomcat網站
Tomcat
wget http://mirrors.hust.edu.cn/apache/tomcat/tomcat-9/v9.0.16/bin/apache-tomcat-9.0.16.tar.gz
tar xf apache-tomcat-9.0.16.tar.gz
cd  apache-tomcat-9.0.16/webapps/ROOT
echo "Tomcat Ab" > tt.html
../../bin/startup.sh

#進行壓力測試
[root@web01 ~]# ab -k -n100000 -c200 http://127.0.0.1/tt.html

瞭解性能指標:node

1.網絡
    網絡的流量
    網絡是否丟包
    這些會影http的請求與調用
2.系統
    硬件有沒有磁盤損壞、磁盤速率
    系統負載、內存、系統穩定性
3.服務
    鏈接優化、請求優化
    根據業務形態作對應的服務設置
4.程序
    接口性能
    處理速度
    程序執行效率
5.數據庫
每一個服務與服務之間都或多或少有一些關聯,咱們須要將整個架構進行分層.找到對應系統或服務的短板,而後進行優化。

三.系統性能優化

文件句柄,Linux-切皆文件,文件句柄能夠理解爲就是一個索引,文件句柄會隨着咱們進程的調用頻繁增長,系統默認文件句柄是有限制的,不能讓一個進程無限的調用,因此咱們須要限制每一個進程和每一個服務使用多大的文件句柄,文件句柄也是必需要調整的優化參數.
文件句柄的設置方式, 1.系統全局性修改。2.用戶局部性修改。3.進行局部性修改jquery

系統層面必需要調整nginx

1.系統全局性修改。
    # *表明全部用戶
    * soft nofile 25535
    * hard nofile 25535

    2.用戶局部性修改。
    root soft nofile 65535
    root hard nofile 65535

    3.進程局部性修改
    worker_rlimit_nofile 65535; #針對Nginx進程(核心模塊)

四.調整內核參數:讓time_wait狀態重用(端口重用)[flag]

[root@web01 ROOT]# vim /etc/sysctl.conf
    net.ipv4.tcp_tw_reuse = 1
    net.ipv4.tcp_timestamps = 1
[root@web01 ROOT]# sysctl -p

五.代理服務優化[flag]

一般Nginx做爲代理服務,負責轉發用戶的請求,那麼在轉發過程當中建議開啓HTTP長鏈接,用於減小握手次數,下降服務器損耗。upstream keepalive說明web

5.1.長鏈接語法示例(應用層面優化)

Syntax: keepalive connections;
Default:-
Context: upstream
This directive appeared in version 1.1.4.

5.2.配置Nginx代理服務使用長鏈接方式

upstream http_backend {
    server 127.0.0.1:8080;
    keepalive 16;   #長鏈接
}

server {
    ...
    location /http/ {
        proxy_pass http://http_backend;
        proxy_http_version 1.1;         #對於http協議應該指定爲1.1
        proxy_set_header Connection ""; #清除「connection」頭字段
        proxy_next_upstream error timeout http_500 http_502 http_503 http_504;  #平滑過渡
        proxy_set_header Host $http_host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwared-For $proxy_add_x_forwarded_for;
        proxy_connect_timeout 30s;      # 代理鏈接web超時時間
        proxy_read_timeout 60s;         # 代理等待web響應超時時間
        proxy_send_timeout 60s;         # web回傳數據至代理超時時間
        proxy_buffering on;             # 開啓代理緩衝區,web回傳數據至緩衝區,代理邊收邊傳返回給客戶端
        proxy_buffer_size 32k;          # 代理接收web響應的頭信息的緩衝區大小
        proxy_buffers 4 128k;           # 緩衝代理接收單個長鏈接內包含的web響應的數量和大小
        ...
    }
}

5.3.對於fastcgi服務器,須要設置fastcgi_keep_conn以便保持長鏈接[flag]

upstream fastcgi_backend {
    server 127.0.0.1:9000;
    keepalive 8;
}

server {
    ...
    location /fastcgi/ {
        fastcgi_pass fastcgi_backend;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        fastcgi_keep_conn on;
        
        fastcgi_connect_timeout 60s;
        include fastcgi_params;
        ...
    }
}

5.4.keepalive_requests設置經過一個keepalive鏈接提供的最大請求數。在發出最大請求數後,將關閉鏈接。

Syntax: keepalive_requests number;
Default: keepalive_requests 100;
Context: upstream
該指令出現&:1.15.3版中。

5.5.keepative_timeout設置超時,在此期間與代理服務器的空閒keepalive鏈接將保持打開狀態。

Syntax: keepalive_timeout timeout;
Default:keepalive_timeout 60s;
Context: upstream
#該指令出如今1.15.3版

注意:
1.scgi和uwsgi協議沒有保持鏈接的概念。
2.但不管是proxy、fastcgi、uwsgi協議都有cache緩存的功能,開啓後可加速網站訪問的效率。(取決硬件)ajax

6、靜態資源優化

nginx做爲靜態資源服務器,用於靜態資源處理,傳輸很是的高效。

靜態資源是指:非WEB服務器端運行處理而生成的文件

靜態資源類型 種類
瀏覽器渲染 HTML、CSS, JS
圖片文件 JPEG、GIF、PNG
讓文件 FLV、Mp四、AVI
其餘文件 TXT、DOC、PDF、•••

6.1.靜態資源緩存

瀏覽器緩存設置用於提升網站性能,尤爲是新聞網站,圖片一旦發佈,改動的多是很是小的。因此咱們但願可否用戶訪問一次後,圖片緩存在用戶的瀏覽器長時間緩存。
瀏覽器是有本身的緩存機制,它是基於HTTP協議緩存機制來實現的,在HTTP協議中有不少頭信息,那麼實現瀏覽器的緩存就須要依賴特殊的頭信息來與服務器進行特殊的驗證,如:Expires (http/1.0) ;Cache-control (http/1.1)。

6.1.1.瀏覽器無緩存

6.1.2.瀏覽器有緩存

6.1.3.瀏覽器緩存過時校驗檢查機制,說明以下:

1.瀏覽器請求服務器會先進行Expires、Cache-Control的檢查,檢查緩存是否過時.若是沒有過時則直接從緩存文件中讀取。
2.若是緩存過時,首先檢查是否存在etag,若是存在則客戶端會向web服務器請求if-None-Match,與etag值進行比對,由服務器決策返回200仍是304。
3.若是etag不存在,則進last-Modified檢查,客戶瑞會向web服務器請求If-Moafied-Since,與last-Modified進行比對,由服務器決策返回200仍是304。

1.如今設置緩存10s中的時間。10s到了 緩存是否是應該過時。
瀏覽器If-None-Match "9-1550193224000"
詢問web服務器 etag "9-1550193224000"
瀏覽器認爲只是緩存過時,內容並無修改,因此協商後仍是304

瀏覽器If-Modified-Since Tue, 29 Jan 2019 02:29:51 GMT
詢問web服務器 Last-Modified: Tue, 29 Jan 2019 02:29:51 GMT
瀏覽器認爲只是緩存過時,內容並無修改,因此協商後仍是304

6.1.4.如何配置靜態資源緩存expires

做用:添加Cache-Control Expires頭
Syntax: expires  [mondified]  time;
expires  epoch | max | off;
Default:expires  off;
Context: http,server,location,if in location

6.1.5.配置靜態資源緩存場景

1.開啓瀏覽器緩存

server {
    listen 80;
    server_name static.bgx.com;
    
    location ~ .*\.(jpg|gif|png)$ {
        expires      7d;
    }
    location ~ .*\.(js|css)$ {
        expires      30d;
    }
}

2.若是開發代碼沒有正式上線時,但願靜態資源不被緩存

location ~ \.*(png|jpg|gif|jpeg)$ {
                add_header Cache-Control no-store;
                add_header Pragma no-cache;
        }
}

6.二、靜態資源讀取

6.2.1.文件讀取高效sendfile,以下圖

Syntax: sendfile on | off;
Default: sendfile off;
Context: http, server, location, if in location


傳統讀取文件方式\zS sendfile讀取文件方式

6.2.2.將多個包一次發送,用於提高網絡傳輸效率,大文件須要打開,須要開啓sendfile 才行

Syntax: tcp_nopush on | off;
Default: tcp_nopush off;
Context: http, server, location

6.2.3.提升網絡傳輸實時性,須要開啓keepalive

Syntax: tcp_nodelay on | off;
Default: tcp_nodelay on;
Context: http, server, location

6.三、靜態資源壓縮

Nginx將響應報文發送至客戶端以前啓用壓縮功能,而後進行傳輸,這可以有效地節約帶寬,並提升響應至客戶端的速度。

6.3.一、gzip傳輸壓縮,傳輸前壓縮,傳輸後解壓

Syntax: gzip on | off;
Default: gzip off;
Context: http, server, location, if in location

6.3.二、gzip壓縮哪些類型的文件

Syntax: gzip_types mime-type ...;
Default: gzip_types text/html;
Context: http, server, location

6.3.三、gzip壓縮比率,加快傳輸,但壓縮自己比較耗費服務端性能

Syntax: gzip_comp_level level;
Default: gzip_comp_level  1;
Context: http, server, location

6.3.四、gzip壓縮協議版本,壓縮使用在http那個協議,主流選擇1.1版本

Syntax: gzip_http_version 1.0 | 1.1;
Default: gzip_http_version  1.1;
Context: http, server, location

6.3.五、靜態圖片配置壓縮案例

[root@Nginx conf.d]# cat static_server.conf 
server {
    listen 80;
    server_name static.oldboy.com;

    location ~*  .*\.(jpg|gif|png)$ {
        root /code/images;
        gzip on;
        gzip_http_version 1.1;
        gzip_comp_level 2;
        gzip_types  image/jpeg image/gif image/png;
        }
}

6.3.六、針對txt配置壓縮案例

[root@Nginx conf.d]# cat static_server.conf 
server {
    listen 80;
    server_name static.oldboy.com;
    sendfile on;
    location ~ .*\.(txt|xml|html|json|js|css)$ {
        gzip on;
        gzip_http_version 1.1;
        gzip_comp_level 1;
        gzip_types text/plain application/json application/x-javascript application/css application/xml text/javascript;
    }
}

6.四、防止資源盜鏈

防盜鏈,指的是防止資源被其餘網站惡意盜用。

基礎防盜鏈設置思路:主要是針對客戶端請求過程當中所攜帶的一些Header信息來驗證請求的合法性,好比客戶端在請求的過程當中都會攜帶referer信息(referer會告訴服務器我是從哪個頁面過來的)。優勢是規則簡單,配置和使用都很方便,缺點是防盜鏈所依賴的Referer驗證信息是能夠僞造的,因此經過Referer信息防盜鏈並不是100%可靠,可是它可以限制大部分的盜鏈狀況。

Syntax: valid_referers none | blocked | server_names | string ...;
Default: -
Context: server, location

#none:Referer來源頭部爲空的狀況
#blocked:Referer來源頭部不爲空,這些值都不以http://或者https://開頭
#server_names:來源頭部包含當前的域名,能夠正則匹配

6.4.一、提供資源的服務器:10.0.0.8 www.linanxi.fun

1.配置Nginx

[root@web02 conf.d]# cat static.conf 
server {
    listen 80;
    server_name www.linanxi.fun;
    root /code;

    location / {
        index index.html;
    }
}

2.上傳2張圖片
一張是能夠被盜鏈的圖片
一張是廣告位的圖片:此圖爲了rewrite給盜鏈的人

3.重啓服務器

[root@web02 code]# systemctl restart nginx

6.4.二、盜鏈服務器10.0.0.7 dl.oldboy.com

1.配置Nginx

[root@web01 conf.d]# cat try.conf
server {
    server_name dl.oldboy.com;
    listen 80;
    root /code;
    location / {
        index index.html;
    }
}

2.在盜鏈服務器上,配置盜鏈的頁面,偷取www.linanxi.fun網站上的圖片

[root@web01 code]# cat /code/tt.html
<html>
<head>
    <meta charset="utf-8">
    <title>oldboyedu.com</title>
</head>
<body style="background-color:red;">
    <img src="http://www.linanxi.fun/smg.jpg"/>   #根據狀況修改你的服務器地址
</body>
</html>

6.4.三、在10.0.0.8 添加防盜鏈操做

location ~* \.(gif|jpg|png|bmp)$ {
  valid_referers none blocked *.linanxi.fun;
  if ($invalid_referer) {
      return 403;                       #能夠選擇直接返回403
      rewrite ^(.*)$ /ggw.png break;        #也能夠選擇返回一張水印的圖片,給公司作廣告
  }

以上配置的含義,全部來自linanxi.fun均可以訪問到當前站點的圖片,若是來源域名不在這個列表中,那麼$invalid_referer等於1,在if語句中返回一個403給用戶,這樣用戶就會看到一個403頁面。

6.4.四、若是須要谷歌、百度等使用(盜鏈)咱們的資源,須要以下操做:

location ~* \.(gif|jpg|png|bmp)$ {
  valid_referers none blocked *.linanxi.fun  server_name  ~\.google\.  ~\.baidu\.;
  if ($invalid_referer) {
      return 403;                       #能夠選擇直接返回403
      rewrite ^(.*)$ /ggw.png break;        #也能夠選擇返回一張水印的圖片,給公司作廣告
  }

6.五、跨站訪問

什麼是跨站訪問,當咱們經過瀏覽器訪問a網站時,同時會利用到ajax或其餘方式,同時也請求b網站,這樣的話就出現了請求一個頁面,使用了2個域名,這種方式對瀏覽器來講默認是禁止。

那Nginx容許跨站訪問與瀏覽器有什麼關係呢,由於瀏覽器會讀取Access-Control-Allow-Origin的頭信息,若是服務端容許,則瀏覽器不會進行攔截。

Syntax: add_header name value [always];
Default: 一
Context: http,server,location,if in location

1.在a網站上準備跨站訪問的文件

[root@Nginx ~]# cat /code/http_origin.html 
<html lang="en">
<head>
        <meta charset="UTF-8" />
        <title>測試ajax和跨域訪問</title>
        <script src="http://libs.baidu.com/jquery/2.1.4/jquery.min.js"></script>
</head>
<script type="text/javascript">
$(document).ready(function(){
        $.ajax({
        type: "GET",
        url: "http://fj.xuliangwei.com/public/tt.html",         #調用的也是b網站
        success: function(data) {
                alert("sucess!!!");
        },
        error: function() {
                alert("fail!!,請刷新再試!");
        }
        });
});
</script>
        <body>
                <h1>測試跨域訪問</h1>
        </body>
</html>

2.準備b網站
3.經過瀏覽器測試跨域訪問

4.在b網站上容許a網站跨域訪問

[root@Nginx conf.d]# cat fj.xuliangwei.com.conf 
location ~ .*\.(html|htm)$ {
    add_header Access-Control-Allow-Origin *;
    add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS;
}

6.六、cpu親和配置

CPU親和(affinity)減小進程之間不斷頻繁切換,減小性能損耗,其實現原理是將CPU核心和Nginx工做進程綁定方式,把每一個worker進程固定對應的cpu上執行,減小切換cpu的cache miss,得到更好的性能。

1.查看當前CPU物理狀態

[root@nginx ~]# lscpu |grep "CPU(s)"
CPU(s):                24               #總的核心數
On-line CPU(s) list:   0-23
NUMA node0 CPU(s):     0,2,4,6,8,10,12,14,16,18,20,22
NUMA node1 CPU(s):     1,3,5,7,9,11,13,15,17,19,21,23

每一個物理cpu使用的是那些核心(表明2顆物理CPU,)
本次演示服務器爲 兩顆物理cpu,每顆物理CPU12個核心, 總共有24個核心

2.將Nginx worker進程綁定到不一樣的核心上。

#最佳方式,修改nginx啓動的work進程爲自動。
worker_processes  auto;
worker_cpu_affinity auto;
不推薦調整的方式
    # 第一種綁定組合方式
    worker_processes 24;
    worker_cpu_affinity 000000000001 000000000010 000000000100 000000001000 000000010000 000000100000 000001000000 000010000000 000100000000 001000000000 010000000000 10000000000;

    # 第二種方式(使用較少)
    worker_processes 2;
    worker_cpu_affinity 101010101010 010101010101;

3.查看nginx worker進程綁定至對應的CPU

[root@web01 ~]# ps -eo pid,args,psr|grep [n]ginx
  1242 nginx: master process /usr/   2
  1243 nginx: worker process         0
  1244 nginx: worker process         1
  1245 nginx: worker process         2
  1246 nginx: worker process         3

6.七、Nginx通用配置

Nginx通用配置 / Nginx代理相關配置 / Nginx Fastcgi能夠寫三個模板。
Nginx主配置文件:

[root@nginx ~]# cat nginx.conf
user www;                        # nginx進程啓動用戶
worker_processes auto;       #與cpu核心一致便可
worker_cpu_affinity auto;        # cpu親和

error_log /var/log/nginx/error.log warn;    # 錯誤日誌
pid /run/nginx.pid;
worker_rlimit_nofile 35535;     #每一個work能打開的文件描述符,調整至1w以上,負荷較高建議2-3w

events {
    use epoll;                  # 使用epoll高效網絡模型
    worker_connections 10240;   # 限制每一個進程能處理多少個鏈接,10240x[cpu核心]
}

http {
    include             mime.types;
    default_type        application/octet-stream;
    charset utf-8;      # 統一使用utf-8字符集

    #定義日誌格式
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
    
    access_log  /var/log/nginx/access.log  main;    # 訪問日誌
    
    server_tokens off;  # 禁止瀏覽器顯示nginx版本號
    client_max_body_size 200m;  # 文件上傳大小限制調整
    
    #文件高效傳輸,靜態資源服務器建議打開
    sendfile            on;
    tcp_nopush          on;
    # 文件實時傳輸,動態資源服務建議打開,須要打開keepalive
    tcp_nodelay         on;
    keepalive_timeout   65;
    
    # Gzip 壓縮
    gzip on;
    gzip_disable "MSIE [1-6]\.";
    gzip_http_version 1.1;
    gzip_comp_level 2;
    gzip_buffers 16 8k;
    gzip_min_length 1024;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml applicati
on/xml+rss text/javascript image/jpeg;

    # 虛擬主機
    include /etc/nginx/conf.d/*.conf;
}

7、Nginx安全與優化總結

1.cpu親和、worker進程數、調整每一個worker進程打開的文件數
2.使用epool網絡模型、調整每一個worker進程的最大鏈接數
3.文件的高效讀取sendfile、nopush、
4.文件的傳輸實時性、nodealy
5.開啓tcp長連接、以及長連接超時時間keepalived
6.開啓文件傳輸壓縮gzip
7.開啓靜態文件expires緩存
8.隱藏Nginx的版本號
9.禁止經過IP地址訪問,禁止惡意域名解析,只容許域名訪問
10.配置放盜鏈、以及跨域訪問
11.防DDOS、cc攻擊, 限制單IP併發鏈接,以及http請求
12.優雅限制nginx錯誤頁面
13.nginx加密傳輸https優化
14.nginx proxy_cache、fastcgi_cache、uwsgi_cache緩存
            squid、varnish()

8、PHP服務優化

8.1.php程序配置管理文件/etc/php.ini,主要調整日誌、文件上傳、禁止危險函數、關閉版本號顯示等

#;;;;;;;;;;;;;;;;;
# Error  logging ;  #錯誤日誌設置
#;;;;;;;;;;;;;;;;;
expose_php = Off                        # 關閉php版本信息
display_error = Off                     # 屏幕不顯示錯誤日誌
error_reporting = E_ALL                 # 記錄PHP的每一個錯誤
log_errors = On                         # 開啓錯誤日誌
error_log = /var/log/php_error.log      # 錯誤日誌寫入的位置
date.timezone = Asia/Shanghai           # 調整時區,默認PRC

#;;;;;;;;;;;;;;;
# File Uploads ;    #文件上傳設置
#;;;;;;;;;;;;;;;
file_uploads = On           # 容許文件上傳
upload_max_filesize = 300M  # 容許上傳文件的最大大小
post_max_size = 300M        # 容許客戶端單個POST請求發送的最大數據
max_file_uploads = 20       # 容許同時上傳的文件的最大數量
memory_limit = 128M         # 每一個腳本執行最大內存

[Session]       #會話共享
session.save_handler = redis
session.save_path = "tcp://172.16.1.51:6379"

禁止危險函數的詳細講解:https://blog.csdn.net/unixtech/article/details/53761832
php禁止危險函數執行(取決於實際狀況,須要和開發溝通)
disable_functions = chown,chmod,pfsockopen,phpinfo

8.2.php-fpm進程管理配置文件/etc/php-fpm.conf

#第一部分,fpm配置
;include=etc/fpm.d/*.conf

#第二部分,全局配置
[global]
;pid = /var/log/php-fpm/php-fpm.pid     #pid文件存放的位置
;error_log = /var/log/php-fpm/php-fpm.log   #錯誤日誌存放的位置
;log_level = error  #日誌級別, alert, error, warning, notice, debug
rlimit_files = 65535     #php-fpm進程能打開的文件數
;events.mechanism = epoll #使用epoll事件模型處理請求

#第三部分,進程池定義
[www]       #池名稱
user = www  #進程運行的用戶
group = www #進程運行的組
;listen = /dev/shm/php-fpm.sock #監聽在本地socket文件
listen = 127.0.0.1:9000         #監聽在本地tcp的9000端口
;listen.allowed_clients = 127.0.0.1 #容許訪問FastCGI進程的IP,any不限制 

pm = dynamic                         #動態調節php-fpm的進程數
pm.max_children = 512           #最大啓動的php-fpm進程數
pm.start_servers = 32            #初始啓動的php-fpm進程數
pm.min_spare_servers = 32    #最少的空閒php-fpm進程數
pm.max_spare_servers = 64   #最大的空閒php-fpm進程數
pm.max_requests = 1500        #每個進程能響應的請求數
pm.process_idle_timeout = 15s;
pm.status_path = /phpfpm_status #開啓php的狀態頁面

#第四部分,日誌相關
php_flag[display_errors] = off
php_admin_value[error_log] = /var/log/phpfpm_error.log
php_admin_flag[log_errors] = on


#慢日誌
request_slowlog_timeout = 5s    #php腳本執行超過5s的文件
slowlog = /var/log/php_slow.log #記錄至該文件中

慢日誌示例
[21-Nov-2013 14:30:38] [pool www] pid 11877
script_filename = /usr/local/lnmp/nginx/html/www.quancha.cn/www/fyzb.php
[0xb70fb88c] file_get_contents() /usr/local/lnmp/nginx/html/www.quancha.cn/www/fyzb.php:2

8.三、php-fpm監控模塊,用於監控php-fpm狀態使用

[root@nginx ~]# vim /etc/php-fpm.d/www.conf
pm.status_path = /phpfpm_status #開啓php的狀態頁面

#修改nginx配置:加一個location
新增配置以下:
location /phpfpm_status {
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}

狀態顯示以下:
[root@nginx ~]# curl http://127.0.0.1/phpfpm_status
pool:                 www           #fpm池名稱,大多數爲www
process manager:      dynamic       #動態管理phpfpm進程
start time:           05/Jul/2016   #啓動時間,若是重啓會發生變化
start since:          409           #php-fpm運行時間
accepted conn:        22            #當前池接受的鏈接數
listen queue:         0     #請求等待隊列,若是這個值不爲0,那麼須要增長FPM的進程數量
max listen queue:     0     #請求等待隊列最高的數量
listen queue len:     128   #請求等待隊列的長度
idle processes:       4     #php-fpm空閒的進程數量
active processes:     1     #php-fpm活躍的進程數量
total processes:      5     #php-fpm總的進程數量
max active processes: 2     #php-fpm最大活躍的進程數量(FPM啓動開始計算)
max children reached: 0     #進程最大數量限制的次數,若是數量不爲0,則說明phpfpm最大進程數量太小,能夠適當調整。

8.四、PHP-FPM配置文件 4核16G、4核32G

[root@nginx ~]# cat /etc/php-fpm.d/www.conf
[global]
pid = /var/run/php-fpm.pid

error_log = /var/log/php-fpm.log
log_level = warning
rlimit_files = 655350
events.mechanism = epoll

[www]
user = nginx
group = nginx
listen = 127.0.0.1:9000
listen.allowed_clients = 127.0.0.1

pm = dynamic
pm.max_children = 512
pm.start_servers = 32
pm.min_spare_servers = 32
pm.max_spare_servers = 64
pm.process_idle_timeout = 15s;
pm.max_requests = 2048
pm.status_path = /phpfpm_status

#php-www模塊錯誤日誌
php_flag[display_errors] = off
php_admin_value[error_log] = /var/log/php/php-www.log
php_admin_flag[log_errors] = on

#php慢查詢日誌
request_slowlog_timeout = 5s
slowlog = /var/log/php-slow.log

9、總結:

nginx

硬件層面        代理比較的消耗CPU、內存、          靜態比較消耗磁盤IO、
    網絡層面        網絡帶寬大小、傳輸速率、是否有丟包、
    系統層面        調整文件描述。  timewait重用
    應用層面        nginx做爲代理    keepalive 長鏈接
    服務層面        nginx做爲靜態    瀏覽器緩存、文件傳輸、壓縮、防盜鏈、跨域訪問、CPU親和
                nginx做爲緩存    proxy_cache fastcgi_cache uwsgi_cache
                nginx做爲安全    nginx+lua實現waf防火牆

php

php.ini     錯誤日誌記錄、文件大小的調整、session會話共享的配置、禁止沒必要要的函數(與開發協商)
    php-fpm     監聽地址、進程的動態調節、日誌開啓。
    php狀態       php自身監控的狀態信息
    php慢查詢  什麼時間、什麼進程、運行什麼文件、哪一個函數、第幾行達到了超時時間
相關文章
相關標籤/搜索