nginx+php的性能優化設置是什么意思

這篇文章主要介紹“nginx+php的性能優化設置是什么意思”，在日常操作中，相信很多人在nginx+php的性能優化設置是什么意思問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”nginx+php的性能優化設置是什么意思”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

準備工作

• 一臺ECS服務器

• 手動編譯nginx+php

• 修改index.php ,輸出 ‘hello world’

• 用ab工具，ab -c 100 -n 50000 ,連續5次，記錄壓測的qps平均值。

• 想辦法去優化，調整各種參數。每次調整一個參數有發現QPS提高，那就記錄下來，并思考qps瓶頸是在哪

Nginx 一些基本配置的描述

 user administrator administrators;  #配置用戶或者組，默認為nobody nobody。
 worker_processes 2;  #允許生成的進程數，默認為1
 pid /nginx/pid/nginx.pid;   #指定nginx進程運行文件存放地址
 error_log log/error.log debug;  #制定日志路徑，級別。這個設置可以放入全局塊，http塊，server塊，級別以此為：debug|info|notice|warn|error|crit|alert|emerg
 events { accept_mutex on;   #設置網路連接序列化，防止驚群現象發生，默認為on multi_accept on;  #設置一個進程是否同時接受多個網絡連接，默認為off #use epoll;      #事件驅動模型，select|poll|kqueue|epoll|resig|/dev/poll|eventport worker_connections  1024;    #最大連接數，默認為512
 }
 http { include       mime.types;   #文件擴展名與文件類型映射表 default_type  application/octet-stream; #默認文件類型，默認為text/plain #access_log off; #取消服務日志     log_format myFormat '$remote_addr–$remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for'; #自定義格式 access_log log/access.log myFormat;  #combined為日志格式的默認值 sendfile on;   #允許sendfile方式傳輸文件，默認為off，可以在http塊，server塊，location塊。 sendfile_max_chunk 100k;  #每個進程每次調用傳輸數量不能大于設定的值，默認為0，即不設上限。 keepalive_timeout 65;  #連接超時時間，默認為75s，可以在http，server，location塊。
 upstream mysvr {   
       server 127.0.0.1:7878;   server 192.168.10.121:3333 backup;  #熱備 } error_page 404 https://www.baidu.com; #錯誤頁 server { keepalive_requests 120; #單連接請求上限次數。 listen       4545;   #監聽端口 server_name  127.0.0.1;   #監聽地址        location  ~^.+$ {       #請求的url過濾，正則匹配，~為區分大小寫，~為不區分大小寫。#root path;  #根目錄#index vv.txt;  #設置默認頁proxy_pass  http://mysvr;  #請求轉向mysvr 定義的服務器列表deny 127.0.0.1;  #拒絕的ipallow 172.18.5.54; #允許的ip            } 
     }}

接下來我們開始吧

ECS配置
CPU： 1核
內存： 1 GiB
操作系統： CentOS 7 64位
當前使用帶寬： 1Mbps

在高并發的情況下，內核會認為系統受到了SYN flood攻擊，會發送cookies（possible SYN flooding on port 80. Sending cookies），這樣會減慢影響請求的速度，所以在應用服務器上設置下這個參數為0禁用系統保護就可以進行大并發測試了：

 $ vim /etc/sysctl.conf  $ net.ipv4.tcp_syncookies = 0 $ sysctl -p $ net.ipv4.tcp_syncookies = 0

net.ipv4.tcp_syncookies = 0 #此參數是為了防止洪水攻擊的，但對于大并發系統，要禁用此設置
net.ipv4.tcp_max_syn_backlog#參數決定了SYN_RECV狀態隊列的數量，一般默認值為512或者1024，即超過這個數量，系統將不再接受新的TCP連接請求，一定程度上可以防止系統資源耗盡。可根據情況增加該值以接受更多的連接請求。
net.ipv4.tcp_tw_recycle#參數決定是否加速TIME_WAIT的sockets的回收，默認為0。
net.ipv4.tcp_tw_reuse#參數決定是否可將TIME_WAIT狀態的sockets用于新的TCP連接，默認為0。
net.ipv4.tcp_max_tw_buckets#參數決定TIME_WAIT狀態的sockets總數量，可根據連接數和系統資源需要進行設置

默認編譯測試，無修改：

ab -c 100 -n 50000 http://127.0.0.1/index.php
1、 7111 2、7233 3、7240 4、7187 5、7197 平均：7194

修改

worker_processes 1 => auto

worker_processes ：工作進程數，調整一般為auto或者跟cpu核心一樣的數量。

一般一個進程足夠了，你可以把連接數設得很大。（worker_processes: 1，worker_connections: 10,000）
如果有SSL、gzip這些比較消耗CPU的工作，而且是多核CPU的話，可以設為和CPU的數量一樣。(worker_processes: CPU核心數)
或者要處理很多很多的小文件，而且文件總大小比內存大很多的時候，也可以把進程數增加，以充分利用IO帶寬（主要似乎是IO操作有block）

1、 7242 2、7228 3、7275 4、7234 5、7231 平均：7242

worker_connections 1020 => 65535

單個進程允許的客戶端最大連接數，一般來說，連接數可以設置和端口數一樣。

1、 7212 2、7236 3、7223 4、7260 5、7230 平均 7232

worker_rlimit_nofile 65535

worker進程最大打開文件數，一般可以優化設置成和端口數一樣

1、 7243 2、7236 3、7146 4、7243 5、7196 平均 7212.8

use epoll;

使用epoll的I/O模型，事件處理模型優化。

1、7265 2、7196 3、7227 4、7216 5、7253 平均 7231

multi_accept ON

multi_accept指令使得NGINX worker能夠在獲得新連接的通知時盡可能多的接受連接。 此指令的作用是立即接受所有連接放到監聽隊列中。 如果指令被禁用，worker進程將逐個接受連接。
1、 7273 2、7281 3、7308 4、7299 5、7290 平均 7290

accept_mutex ON

由于我們在NGINX中配置了多個workers，因此我們還應配置影響worker的相關指令。 events區域下accept_mutex參數將使每個可用的worker進程逐個接受新連接。設置網路連接序列化，防止驚群現象發生，默認為on。
服務器是1核，所以影響不大
1、7268 2、7295 3、7308 4、7274 5、7261 平均 7281

tcp_nopush On

TCP_CORK作為Nagle算法的替代方案，Linux提供了TCP_CORK選項。 該選項告訴TCP堆棧附加數據包，并在它們已滿或當應用程序通過顯式刪除TCP_CORK指示發送數據包時發送它們。 這使得發送的數據分組是最優量，并且因此提高了網絡的效率。
NGINX提供了tcp_nopush指令，在連接套接字時啟用TCP_CORK。 該指令可用于http，server和location區塊：
http{
     tcp_nopush on;
}
1、7309 2、7321 3、7292 4、7308 5、7322 平均 7310

tcp_nodelay on

TCP/IP網絡存在“小包”問題，其中單字符消息可能在高負載網絡上導致網絡擁塞。 例如分組大小為41字節，其中40字節用于TCP報頭，只有1字節是有用信息。 這些小包占用了大約4000％的巨大開銷并且使得網絡飽和
ohn Nagle通過不立即發送小包來解決問題（Nagle的算法）。 所有這樣的分組被收集一定量的時間，然后作為單個分組一次發送。 這改進了底層網絡的的效率。 因此，典型的TCP/IP協議棧在將數據包發送到客戶端之前需要等待200毫秒。
在打開套接字時可以使用TCP_NODELAY選項來禁用Nagle的緩沖算法，并在數據可用時立即發送。 NGINX提供了tcp_nodelay指令來啟用此選項。 該指令可用于http，server和location區塊：
http{
     tcp_nodelay on;
}

1、 7326 2、7316 3、7334 4、7274 5、7290 平均 7308

worker_priority -5

指明worker進程的nice值
Linux系統中，優先級高的進程會占用更多的系統資源，這里配置的是進程的靜態優先級，取值范圍-20到+19，-20級別最高。因此可以把這個值設置小一點，但不建議比內核進程的值低（通常為-5）

測試中 0到-5的性能提升明顯 0可達到8000均值
1、 7982 2、8023 3、7932 4、7911 5、8052 平均 7980

php-fpm參數調優

pm = dynamic; 
表示使用哪種進程數量管理方式
　　　　dynamic表示php-fpm進程數是動態的，最開始是pm.start_servers指定的數量，如果請求較多，則會自動增加，保證空閑的進程數不小于pm.min_spare_servers，如果進程數較多，也會進行相應清理，保證多余的進程數不多于pm.max_spare_servers
　　　　static表示php-fpm進程數是靜態的, 進程數自始至終都是pm.max_children指定的數量，不再增加或減少
　　1.pm.start_servers = 15; 動態方式下的起始php-fpm進程數量
　　2.pm.min_spare_servers = 5; 動態方式下的最小php-fpm進程數量
3.pm.max_spare_servers = 25; 動態方式下的最大php-fpm進程數量
4.pm.max_requests = 5000
設置每個子進程重生之前服務的請求數. 對于可能存在內存泄漏的第三方模塊來說是非常有用的. 如果設置為 ’0′ 則一直接受請求. 等同于 PHP_FCGI_MAX_REQUESTS 環境變量. 默認值: 0.這段配置的意思是，當一個 PHP-CGI 進程處理的請求數累積到 5000 個后，自動重啟該進程。
7934 2 、8107 3 、8013 4、8039 5、7990 均值 8016

opcache

opcache 絕對是優化的利器，Opcache是字節碼緩存，也就是PHP在被編譯的時候，首先會把php代碼轉換為字節碼，字節碼然后被執行。
php文件第二次執行時，同樣還是會重新轉換為字節碼，但是很多時候，文件內容幾乎是一樣的，比如靜態HTML文件，生成后內容許久都不會改變，用戶訪問請求直接由服務器讀取響應給客戶端瀏覽器。都不用經過PHP進行解析構建了。
內存中的字節碼數據，可以直接緩存進行二次編譯。這樣程序就會快一些，cpu的消耗也少了。

結論

php-fpm 采用 prefork的方式 （listen同一個地址，然后fork出若干子進程),fast-cgi管理器實現的是多進程模型。

但是在php運行時，每一個進程只能處理一個請求，實際上，運行時是單進程，單線程的。

php-fpm一個線程是阻塞模型，必須等待該客戶端請求php服務端返回數據，下一個nginx發過來的請求才能被受理，這個時候FPM就需要增多進程去應付并發，更高的qps 需要更多的進程處理，當處理請求的時候發生了時間較長阻塞，導致進程內存無法釋放，后續請求沒有足夠的子進程去處理，更多的瓶頸在于 PHP-FPM 大量子進程的處理和消耗內存上面。

到此，關于“nginx+php的性能優化設置是什么意思”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！