記一次PHP優化案例

                                                                  記一次php優化案例

網站架構簡介：

如今不少的企業都是使用lnmp或者lamp來作企業的網站服務器架構，這兩種網站的服務架構，咱們都是比較熟悉的；基於nginx的性能優於Apache，現階段的不少公司，都是逐漸把Apache替換成nginx，畢竟nginx的自帶的高可用配置，反向代理等等功能至關突出。

    Lnmp網站服務器架構,其實就是linx+nginx+mysql+php架構體系，架構安裝我就很少說了。接下來咱們來談談，我遇到案例吧

 

案例：

有一天，後臺的同事，說後臺訪問很慢，並且有時候出現502錯誤。而後反饋給技術上級，接着又找到我處理一下（那時在喝着茶），而後我知道又有事幹了。

分析：

而後我直接找到那個同事，問問是否是網絡緣由啊，我也叫其餘的同事，訪問一下，仍是出現訪問忙的問題。這時我就知道事情沒那麼簡單了。公司應用的是lnmp網站服務器架構,之前沒有作太多的優化，接下來咱們須要優化網站的服務架構了

 

1、案例分析。

   咱們能夠想到，既然是訪問緩慢，有時候直接訪問不了，之前是沒問題的，到如今就忽然出現了問題，那一定是咱們的nginx與php響應不過來致使的，緣由多是其餘域名網站的用戶鏈接數巨增致使的。那咱們找到問題的根源解決並優化就能夠了。接着憑着本身的經驗與百度，去解決問題。

  

2、問題解決與過程分析

 

1、Nginx優化：  

 1、查看nginx的日誌，找出錯誤

$ cat /usr/local/nginx/logs/error.log | grep error

  

沒發現錯誤，正常

查看後臺域名的access.logs

$ cat /var/log/access_nging.log | grep error

(這裏沒及時截到圖，日誌是被刷了，本地作了日誌切割，並定時刪除了)

發現日誌日誌裏面能夠找到error錯誤信息，而且有十幾個502錯誤。找到出現的問題了。

2、問題分析以及nginx優化

  1、nginx打開文件數限制致使的。

1)、首先咱們想到可能的緣由nginx的打開文件書的問題，增長nginx的打開文件數

進入nginx配置文件，發現打開文件數爲4096,果不其然，打開文件數沒有調到最佳，多是這個緣由致使的。咱們須要把4096改成51200；保存從新加載nginx

# vim /usr/local/nginx/conf/nginx.conf

worker_rlimit_nofile 51200;

events {

  worker_connections 51200;

}

#service nginx relaod

 2）、Linux系統文件限制

   咱們改了nginx的打開文件配置，不必定有用，咱們須要看一下系統的限制的打開文件數

# ulimit –n

  

 咱們能夠看到系統的文件打開數量也是4096，接下來，咱們更改一下系統的打開文件數，並配置永久生效。

  進入配置文件

# vim /etc/security/limits.conf

更改參數：

* soft nofile 65535

* hard nofile 65535

* soft nproc 65535

* hard nproc 65535

 注：系統限制能夠隨便改，我只要比nginx的打開文件數大就好。

3、nginx的fastcgi鏈接時間過短致使的。

   通常nginx響應php，都是經過FastCGI接口來調用，因此fastcgi參數配置很重要，當HTTP服務器每次遇到動態程序時，能夠將其直接交付給FastCGI進程來執行，而後將獲得的結果返回給瀏覽器，而不少php的網頁都是採用動態程序。因此fastcgi的配置，也起的相當重要的做用。因此這是一個優化不可缺乏的一部分。

進入nginx.conf配置文件

# vim /usr/local/nginx/conf/nginx.conf

把fastcgi的connect、send、read的參數的時間改爲300，配置以下：

從新加載nginx

#service nginx reload

4、訪問域名測試。

  從新訪問域名，發現網頁已經加載出來了，持續訪問了幾回，發現訪問仍是有點慢，雖然訪問穩定了。到這裏，咱們就能夠把問題指向到php裏面了，繼續下一步的php優化。

 

2、Php優化：

 1、查看php日誌

 首先，咱們須要跟nginx的操做同樣，須要先查看一下日誌。

#tail -n 100 /usr/local/php/var/log/php-fpm.log

在日誌裏面咱們能夠發現，php日誌出現警告

WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers)

從告警的意思，咱們知道php出現告警了，並且是叫咱們增長php的，pm.start_servers, or pm.min/max_spare_servers的值。

2、緣由分析

首先咱們，看到日誌只是出現這個警告，證實還不是很嚴重，至於爲何出現這個警告，接下來咱們一塊兒分析一下。

首先咱們很明確的知道，pm.start_servers,、pm.min/max_spare_servers在php裏面是起着啥做用先，爲何會出現這個警告。我先把的之前的配置參數貼一下。

 

接下來咱們分析一下這幾個參數的做用：

參數分析：

• pm= dynamic  表示php啓用的動態模式  注： php有動態和靜態(static)兩種工做模式，默認是動態模式。

• pm.max_children      表示靜態下最大線程數

• pm.start_servers      表示動態下啓動時的線程數，該參數大於pm.min_spare_servers，小於pm.max_spare_servers

• pm.min_spare_servers      表示動態下最小空閒線程數

• pm.max_spare_servers      表示動態下最大空閒線程數

工做模式：

Static模式

當工做模式設置爲靜態後，就只有pm.max_children項有效，即表示php-fpm工做時一直保持的線程數。

Dynamic 模式

動態模式下，與他相關的參數有pm.start_servers、pm.min_spare_servers 、pm.max_spare_servers，分別表示開啓的php進程數，最小的進程數、與最大的進程數。

模式比較：

靜態模式的話，比較適合一些內存比較大一點的服務器，8G及以上的，由於對於比較大內存的服務器來講，設置爲靜態的話會提升效率。

動態模式適合小內存機器，靈活分配進程，省內存。可讓php自動增長和減小進程數，不過動態建立回收進程對服務器也是一種消耗。

 3、php參數優化

    

首先咱們須要考慮一下問題，如何去調試參數，達到優化的目的呢，通常來講開始的時候一個php-fpm進程只佔用3M左右內存，可是運行一段時間後就會上升到20-40M，這是由於PHP程序在執行完成後，或多或少會產生內存的泄露。

因此按理來講php的最大的進程數，大概是本地內存/40，由於也要考慮系統佔用內存的的這種狀況，咱們不能直接把除處理的結果，當成的最大進程數，否則你會死翹翹的。

個人服務器是8G內存的，因此按理來講是，最大的php進程數是200左右，因此按這個參數我作了一下調整：

採用靜態模式，最大進程數設爲125-150之間，搞定。

從新加載php

#service php-fpm relod

查看進程數：

# netstat -anpo | grep php-fpm | wc -l
128

效果達到了

 四、結果

從新訪問，發現訪問php頁面快了不少，查看日誌，沒出現告警了，後臺訪問也好了。

 3、壓測

   一個網站的性能好很差，承受量有多高，這個咱們能夠經過壓測去，去獲取數據，我這裏簡單介紹ab工具來作壓測，用法以下

   ab -n 1000000   -c 10000  http://域名/test.php (一個php文件)

  

   -n參數表示 你壓力測試 總量

   -c參數表示 你的模擬的併發用戶數

Ab壓力測試工具，是apache自帶的，用起來也方便，只要本地有，就能夠遠程測你的服務器的性能了。我的以爲仍是能夠了，下面是模擬一千個用戶訪問100000次的結果，但然你本身壓測的時候，慢慢的提高參數，測試你的網站的瓶頸。

還有分享一下，下面是一個網站性能工具分析網址，你能夠貼一下你的域名，進行評分

 

http://www.mmtrix.com/evaluate/result?popup=true

 

 

3、總結

  問題並不難解決，難的是你沒有思考過，一次我的php優化經歷，互相學習。