性能優化概述

来源:https://www.cnblogs.com/1naonao/archive/2019/09/05/11470403.html
-Advertisement-
Play Games

[toc] 性能優化概述 1、瞭解每個服務 2、需要瞭解業務模式 3、最後我們需要考慮性能與安全 壓力測試工具 瞭解影響性能指標 系統性能優化 文件句柄，Linux一切皆文件，文件句柄可以理解為就是一個索引，文件句柄會隨著我們進程的調用頻繁增加，系統預設文件句柄是有限制的，不能讓一個進程無限的調用， ...


目錄

性能優化概述

1、瞭解每個服務

2、需要瞭解業務模式

3、最後我們需要考慮性能與安全

壓力測試工具

[root@web01 conf.d]# yum install httpd-tools -y

#配置nginx
[root@lb01 conf.d]# cat try.conf 
server {
    listen 80;
    server_name try.haoda.com;

    location / {
    root /code;
        try_files $uri $uri/ @java;
    index index.jsp index.html;
    }

    location @java {
    proxy_pass http://172.16.1.8:8080;
    }
}

#配置nginx使用的靜態頁面
[root@lb01 conf.d]# echo "nginx ab" > /code/ad.html

#配置tomcat使用的靜態頁面
[root@web02 ~]# wget http://mirrors.hust.edu.cn/apache/tomcat/tomcat-9/v9.0.16/bin/apache-tomcat-9.0.16.tar.gz
[root@web02 ~]# tar xf apache-tomcat-9.0.16.tar.gz
[root@web02 ~]# cd /usr/share/tomcat/webapps/ROOT
[root@web02 ROOT]# echo "tomcat aaaaa" > tomcat.html

#壓測工具測試nginx處理靜態資源
[root@lb01 conf.d]# ab -n 10000 -c 200 http://try.haoda.com/ad.html

Server Software:        nginx/1.14.2
Server Hostname:        try.haoda.com
Server Port:            80

Document Path:          /ad.html
Document Length:        9 bytes

Concurrency Level:      200
Time taken for tests:   1.078 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      2380000 bytes
HTML transferred:       90000 bytes
Requests per second:    9272.58 [#/sec] (mean)
Time per request:       21.569 [ms] (mean)
Time per request:       0.108 [ms] (mean, across all concurrent requests)
Transfer rate:          2155.15 [Kbytes/sec] received


#壓測工具測試tomcat處理靜態資源
[root@lb01 conf.d]# ab -n 10000 -c 200 http://try.haoda.com/tomcat.html

Server Software:        nginx/1.14.2
Server Hostname:        try.haoda.com
Server Port:            80

Document Path:          /tomcat.html
Document Length:        13 bytes

Concurrency Level:      200
Time taken for tests:   4.956 seconds
Complete requests:      10000
Failed requests:        0
Write errors:           0
Total transferred:      2510000 bytes
HTML transferred:       130000 bytes
Requests per second:    2017.78 [#/sec] (mean)
Time per request:       99.119 [ms] (mean)
Time per request:       0.496 [ms] (mean, across all concurrent requests)
Transfer rate:          494.59 [Kbytes/sec] received

瞭解影響性能指標

1、網路
    （1）網路的流量
    （2）網路是否丟包
    （3）這些會影響http的請求與調用
2、系統
    （1）硬體有沒有磁碟損壞，磁碟速率
    （2）系統的負載、記憶體、系統穩定性
3、服務
    （1）連接優化。請求優化
    （2）根據業務形態做對應的服務設置
4、程式
    （1）介面性能
    （2）處理速度
    （3）程式執行效率
5、資料庫

#每個服務與服務之間都或多或少有一些關聯，我們需要將整個架構進行分層，找到對應系統或服務的短板，然後進行優化

系統性能優化

文件句柄，Linux一切皆文件，文件句柄可以理解為就是一個索引，文件句柄會隨著我們進程的調用頻繁增加，系統預設文件句柄是有限制的，不能讓一個進程無限的調用，所以我們需要限制每個 進程和每個服務使用多大的文件句柄，文件句柄也是必須要調整的優化參數。

文件句柄的設置方式：
1、系統全局性修改。
2、用戶局部性修改。
3、進程局部性修改。

[root@lb01 ~]# vim /etc/security/limits.conf

1、系統全局性修改。
# * 代表所有用戶
* soft nofile 25535
* hard nofile 25535

2.用戶局部性修改
#針對root用戶，soft僅提醒，hard限制，nofile打開最大文件數
root soft nofile 65535
root hard nofile 65535

3.進程局部性修改
#針對nginx進程，nginx自帶配置
worker_rlimit_nofile 30000
4.調整內核參數：讓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    #可以查看我們添加的內核參數
[root@web01 ROOT]# sysctl -a    #可以查看所有內核參數

在高併發短連接的TCP伺服器上，當伺服器處理完請求後立刻主動正常關閉連接。這個場景下會出現大量socket處於TIME_WAIT狀態。如果客戶端的併發量持續很高，此時部分客戶端就會顯示連接不上。 我來解釋下這個場景。主動正常關閉TCP連接，都會出現TIMEWAIT。

為什麼我們要關註這個高併發短連接呢？有兩個方面需要註意： 1. 高併發可以讓伺服器在短時間範圍內同時占用大量埠，而埠有個0~65535的範圍，並不是很多，刨除系統和其他服務要用的，剩下的就更少了。 2. 在這個場景中，短連接表示“業務處理+傳輸數據的時間 遠遠小於 TIMEWAIT超時的時間”的連接。

這裡有個相對長短的概念，比如取一個web頁面，1秒鐘的http短連接處理完業務，在關閉連接之後，這個業務用過的埠會停留在TIMEWAIT狀態幾分鐘，而這幾分鐘，其他HTTP請求來臨的時候是無法占用此埠的(占著茅坑不拉翔)。單用這個業務計算伺服器的利用率會發現，伺服器乾正經事的時間和埠（資源）被掛著無法被使用的時間的比例是 1：幾百，伺服器資源嚴重浪費。（說個題外話，從這個意義出發來考慮伺服器性能調優的話，長連接業務的服務就不需要考慮TIMEWAIT狀態。同時，假如你對伺服器業務場景非常熟悉，你會發現，在實際業務場景中，一般長連接對應的業務的併發量並不會很高。

代理服務優化

配置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響應的數量和大小
    ...
    }
}

對於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;
        ...
    }
}

keepalive_requests設置通過一個keepalive連接提供的最大請求數，在發出最大請求數後，將關閉連接。

Syntax: keepalive_requests number;
Default: keepalive_requests 100;
Context: upstream

keepalive_timeout設置超時，再次期間與代理伺服器的空閑keepalive連接將保持打開狀態。

Syntax: keepalive_timeout timeout;
Default: keepalive_timeout 60s;
Context: upstream

#該指令出現在1.15.3版中

註意:
1.scgi和uwsgi協議沒有保持連接的概念。
2.但無論是proxy、fastcgi、uwsgi協議都有cache緩存的功能，開啟後可加速網站訪問的效率。（取決硬體）

靜態資源緩存

瀏覽器無緩存

瀏覽器有緩存

瀏覽器過期校驗機制

瀏覽器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

配置靜態資源緩存場景

server {
    listen 80;
    server_name static.haoda.com;

    location ~ .*\.(jpg|gif|png)$ {
        expires      7d;
    }
    location ~ .*\.(js|css)$ {
        expires      30d;
    }
}

取消緩存

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

靜態資源壓縮

文件讀取高效sendfile，如下圖

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

傳統讀取文件方式 與 sendfile讀取文件方式

將多個包一次發送，用於提升網路傳輸效率，大文件推薦打開，需要開啟sendfile才行

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

提高網路傳輸實時性，需要開啟keepalive，來一個包發一個包不等待

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

gzip壓縮比率，加快傳輸，但壓縮本身比較耗費伺服器性能

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

gzip壓縮協議版本，壓縮使用在http哪個協議，主流選擇1.1版本

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

針對圖片

location ~*  .*\.(jpg|gif|png)$ {
    root /code/images;
    gzip on;
    gzip_http_version 1.1;
    gzip_comp_level 2; #極致為9，壓縮的級別
    gzip_types  image/jpeg image/gif image/png; #文件格式
    }

針對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;
    }
}

防止資源盜鏈

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

基礎防盜鏈設置思路：主要是針對客戶端請求過程中所攜帶的一些Header信息來驗證請求的合法性，比如客戶端在請求的過程中都會攜帶referer信息。優點是規則簡單，配置和使用都很方便，缺點是防盜鏈所依賴的Referer驗證信息是可以偽造的，所以通過referer信息防盜鏈並非100%可靠，但是他能夠限制大部分的盜鏈情況。

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

#none: referer來源頭部為空的情況
#blocked: referer來源頭部不為空，這些都不以http://或者https://開頭
#server_name: 來源頭部信息包含當前功能變數名稱，可以正則匹配
Syntax: valid_referers none | blocked | server_name | string ...;
Default: -;
Context: server, location

#none: referer來源頭部為空的情況
#blocked: referer來源頭部不為空，這些都不以http://或者https://開頭
#server_name: 來源頭部信息包含當前功能變數名稱，可以正則匹配

5.4.1 在盜鏈伺服器上準備html文件，偷取我的圖片

<html>
<head>
    <meta charset="utf-8">
    <title>haoda.com</title>
</head>
<body style="background-color:black;">
    <img src="http://39.104.205.72/picture/niu.jpg"/>
</body>
</html>

5.4.2 訪問頁面查看

5.4.3 伺服器上配置防盜鏈

location ~ .*\.(jpg|png|gif) {
    root /data;
    valid_referers none blocked 39.104.205.72;
    if ( $invalid_referer ) {
        return 403;
    }
}

以上配置含義表示，所有來自39.104.205.72都可以訪問到當前站點的圖片，如果來源功能變數名稱不在這個列表中，那麼$invalid_referer等於1，在if語句中返回一個403個客戶，這樣用戶便會看到一個403的頁面

5.4.4 如果不使用return而是用rewrite，那麼盜鏈圖片會返回一個pei.jpg給用戶

location ~ .*\.(jpg|png|gif) {
    root /data;
    valid_referers none blocked 39.104.205.72;
    if ( $invalid_referer ) {
        rewrite ^(.*)$ /picture/pei.jpg break;
    }   
}

5.4.5 如果希望某些網站可以盜鏈

location ~ .*\.(jpg|png|gif) {
    root /data;
    valid_referers none blocked 39.104.205.72 server_name ~\.google\. ~\.baidu\.;
    if ( $invalid_referer ) {
        return 403;
    }   
}

當然這種防護並不能百分百保證資源不被盜鏈，因為我們可以通過命令來修改來源的refer信息。

[root@lb01 conf.d]# curl -e "http://www.baidu.com" -I http://39.104.205.72/picture/niu.jpg
[root@lb01 conf.d]# curl -e "http://39.104.205.72" -I http://39.104.205.72/picture/niu.jpg

生產實踐

1.配置網站

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

2.上傳2張圖片

​ 一張是可以被盜鏈的圖片
​ 一張是廣告位的圖片

重啟伺服器

[root@web02 code]# systemctl restart nginx

3.配置盜鏈伺服器

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

配置盜鏈頁面

[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://static.oldboy.com/smg.jpg"/>   #根據情況修改你的伺服器地址
</body>
</html>

4.web02添加防盜鏈操作

location ~* \.(gif|jpg|png|bmp)$ {
  valid_referers none blocked *.xuliangwei.com server_ names ~\.google\.;
  if ($invalid_referer) {
      return 403;                           #可以選擇直接返回403
      rewrite ^(.*)$ /ggw.png break;        #也可以選擇返回一張水印的圖片，給公司做廣告
  }

允許跨域訪問

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://naonao.lq.com/1.jpg",
        success: function(data) {
                alert("sucess!!!");
        },
        error: function() {
                alert("fail!!,請刷新再試!");
        }
        });
});
</script>
        <body>
                <h1>測試跨域訪問</h1>
        </body>
</html>

2.配置b網站

3.通過瀏覽器測試跨域訪問

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

server {
        server_name  naonao.lq.com;
        listen 80;
        root /code;

        location / {
                index index.html;
        }

        location ~* \.(gif|jpg|png|bmp)$ {
                add_header Access-Control-Allow-Origin *;
                add_header Access-Control-Allow-Methods GET,POST,PUT,DELETE,OPTIONS;
        }
}

cpu親和

1.查看當前CPU物理狀態

[root@nginx ~]# lscpu |grep "CPU(s)"
CPU(s):                24                                       #總的核心數
On-line CPU(s) list:   0-23
每個物理cpu使用的是那些核心（代表2顆物理CPU，）
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，每顆物理CPU12個核心, 總共有24個核心

修改nginx啟動的work進程為自動

worker_processes  auto;
worker_cpu_affinity auto;

[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
不推薦調整的方式
    # 第一種綁定組合方式
    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;

Nginx通用配置 Nginx代理相關配置 Nginx Fastcgi

[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;
}

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()

php優化

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" #有密碼寫？auth=

https://blog.csdn.net/unixtech/article/details/53761832
#php禁止危險函數執行（取決於實際情況，需要和開發溝通）
disable_functions = chown,chmod,pfsockopen,phpinfo

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

3.php 狀態頁面 pm.status_path = /phpfpm_status #開啟php的狀態頁面

配置文件

[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最大進程數量過小,可以適當調整。

4.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

總結

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慢查詢  什麼時間、什麼進程、運行什麼文件、哪個函數、第幾行達到了超時時間

您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • Winform中對ZedGraph的RadioGroup進行數據源綁定，即通過代碼添加選項
    場景 在尋找設置RadioGroup的選項時沒有找到相關博客，在DevExpress的官網找到 怎樣給其添加選項。 DevExpress官網教程： https://documentation.devexpress.com/WindowsForms/DevExpress.XtraEditors.Rad ...
  • Winform中對自定義xml配置文件進行Xml節點的添加與刪除
    場景 Winform中自定義xml配置文件後對節點進行讀取與寫入： https://blog.csdn.net/BADAO_LIUMANG_QIZHI/article/details/100532137 在上面已經對xml配置文件對節點能進行讀取與寫入之後 ，實現對節點元素的 添加與刪除。 關註公眾 ...
  • （五十四）c#Winform自定義控制項-儀錶盤
    前提 入行已經7,8年了，一直想做一套漂亮點的自定義控制項，於是就有了本系列文章。 GitHub：https://github.com/kwwwvagaa/NetWinformControl 碼雲：https://gitee.com/kwwwvagaa/net_winform_custom_contr ...
  • .NET Core 學習資料精選：進階
    介紹 .NET工程化、AOP、異常處理、緩存、日誌、響應優化、上傳下載、健康檢查、後臺任務、認證和授權、安全性、EF Core 等等 ...
  • 相容 .NET Core3.0, Natasha 框架實現 隔離域與熱編譯操作
    關於 Natasha 動態構建已經成為了封裝者們的家常便飯，從現有的開發趨勢來看，普通反射性能之低，會迫使開發者轉向EMIT/表達式樹等構建方式，但是無論是EMIT還是表達式樹，都會依賴於反射的元數據。 Natasha 通過使用 Roslyn技術，已經解決了上述的問題，在保證高效可靠的同時，提供了一 ...
  • Winform中自定義xml配置文件後對節點進行讀取與寫入
    場景 Winform中自定義xml配置文件，並配置獲取文件路徑： https://blog.csdn.net/BADAO_LIUMANG_QIZHI/article/details/100522648 上面已經實現自定義配置文件的配置和讀取的基礎上，繼續對配置文件進行讀取與寫入。 xml配置文件如下 ...
  • Linux inode 詳解
    操作系統的文件數據除了實際內容之外，通常含有非常多的屬性，例如 Linux 操作系統的文件許可權與文件屬性。文件系統通常會將這兩部分內容分別存放在 inode 和 block 中。 ...
  • shell 操作釘釘機器人實現告警提醒
    我們知道，之前的運維告警多通過mail 等方式通知到相應的人員，難以實現隨時隨地的查看。隨著手機APP的發展，很多告警開始發送到IM軟體上去。目前比較常用的是發送到微信和釘釘上，今天我們將重點放在釘釘上。群機器人是釘釘群的高級擴展功能，群機器人可以將第三方服務的信息聚合到群聊中，實現自動化的信息同步 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發（一）：使用.NET MAUI開發第一個安卓APP
    移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ...
  • wpf ToggleButton選中效果和一個登錄界面
    前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ...
  • 彈幕樹洞項目功能新增篇
    項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ...
  • 第27篇 sqlserver2022詳細安裝步驟
    話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ...
  • .NET 開源高性能 MQTT 類庫
    前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出
    Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ...
  • 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期
    目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一)
    1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ...
  • 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作
    本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ...
  • 第28篇 如何.net中實現高效可靠數據同步api
    通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ...
所有分類