基詢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
[root@web01 ~]# yum install httpd-tools -yum
[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
[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進程(核心模塊)
[root@web01 ROOT]# vim /etc/sysctl.conf net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_timestamps = 1 [root@web01 ROOT]# sysctl -p
一般Nginx做爲代理服務,負責轉發用戶的請求,那麼在轉發過程當中建議開啓HTTP長鏈接,用於減小握手次數,下降服務器損耗。upstream keepalive說明web
Syntax: keepalive connections; Default:- Context: upstream This directive appeared in version 1.1.4.
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響應的數量和大小 ... } }
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; ... } }
Syntax: keepalive_requests number; Default: keepalive_requests 100; Context: upstream 該指令出現&:1.15.3版中。
Syntax: keepalive_timeout timeout; Default:keepalive_timeout 60s; Context: upstream #該指令出如今1.15.3版
注意:
1.scgi和uwsgi協議沒有保持鏈接的概念。
2.但不管是proxy、fastcgi、uwsgi協議都有cache緩存的功能,開啓後可加速網站訪問的效率。(取決硬件)ajax
nginx做爲靜態資源服務器,用於靜態資源處理,傳輸很是的高效。
靜態資源是指:非WEB服務器端運行處理而生成的文件
靜態資源類型 | 種類 |
---|---|
瀏覽器渲染 | HTML、CSS, JS |
圖片文件 | JPEG、GIF、PNG |
讓文件 | FLV、Mp四、AVI |
其餘文件 | TXT、DOC、PDF、••• |
瀏覽器緩存設置用於提升網站性能,尤爲是新聞網站,圖片一旦發佈,改動的多是很是小的。因此咱們但願可否用戶訪問一次後,圖片緩存在用戶的瀏覽器長時間緩存。
瀏覽器是有本身的緩存機制,它是基於HTTP協議緩存機制來實現的,在HTTP協議中有不少頭信息,那麼實現瀏覽器的緩存就須要依賴特殊的頭信息來與服務器進行特殊的驗證,如:Expires (http/1.0) ;Cache-control (http/1.1)。
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
做用:添加Cache-Control Expires頭 Syntax: expires [mondified] time; expires epoch | max | off; Default:expires off; Context: http,server,location,if in location
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; } }
Syntax: sendfile on | off; Default: sendfile off; Context: http, server, location, if in location
傳統讀取文件方式\zS sendfile讀取文件方式
Syntax: tcp_nopush on | off; Default: tcp_nopush off; Context: http, server, location
Syntax: tcp_nodelay on | off; Default: tcp_nodelay on; Context: http, server, location
Nginx將響應報文發送至客戶端以前啓用壓縮功能,而後進行傳輸,這可以有效地節約帶寬,並提升響應至客戶端的速度。
Syntax: gzip on | off; Default: gzip off; Context: http, server, location, if in location
Syntax: gzip_types mime-type ...; Default: gzip_types text/html; Context: http, server, location
Syntax: gzip_comp_level level; Default: gzip_comp_level 1; Context: http, server, location
Syntax: gzip_http_version 1.0 | 1.1; Default: gzip_http_version 1.1; Context: http, server, location
[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; } }
[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驗證信息是能夠僞造的,因此經過Referer信息防盜鏈並不是100%可靠,可是它可以限制大部分的盜鏈狀況。
Syntax: valid_referers none | blocked | server_names | string ...; Default: - Context: server, location #none:Referer來源頭部爲空的狀況 #blocked:Referer來源頭部不爲空,這些值都不以http://或者https://開頭 #server_names:來源頭部包含當前的域名,能夠正則匹配
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
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>
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頁面。
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; #也能夠選擇返回一張水印的圖片,給公司作廣告 }
什麼是跨站訪問,當咱們經過瀏覽器訪問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; }
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
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; }
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()
#;;;;;;;;;;;;;;;;; # 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
#第一部分,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
[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最大進程數量太小,能夠適當調整。
[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慢查詢 什麼時間、什麼進程、運行什麼文件、哪一個函數、第幾行達到了超時時間