優化PHP的案例分析

這篇文章主要介紹優化PHP的案例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

網站架構簡介：
現在很多的企業都是使用lnmp或者lamp來做企業的網站服務器架構，這兩種網站的服務架構，我們都是比較熟悉的；基于nginx的性能優于Apache，現階段的很多公司，都是逐漸把Apache替換成nginx，畢竟nginx的自帶的高可用配置，反向代理等等功能相當突出。

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

案例：

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

分析：

然后我直接找到那個同事，問問是不是網絡原因啊，我也叫其他的同事，訪問一下，還是出現訪問忙的問題。這時我就知道事情沒那么簡單了。公司應用的是lnmp網站服務器架構,以前沒有做太多的優化，接下來我們需要優化網站的服務架構了

一、案例分析。

我們可以想到，既然是訪問緩慢，有時候直接訪問不了，以前是沒問題的，到現在就突然出現了問題，那必定是我們的nginx與php響應不過來導致的，原因可能是其他域名網站的用戶連接數巨增導致的。那我們找到問題的根源解決并優化就可以了。接著憑著自己的經驗與百度，去解決問題。

二、問題解決與過程分析

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`

效果達到了

4、結果

重新訪問，發現訪問php頁面快了很多，查看日志，沒出現告警了，后臺訪問也好了。

3、壓測

一個網站的性能好不好，承受量有多高，這個我們可以通過壓測去，去獲取數據，我這里簡單介紹ab工具來做壓測，用法如下

ab -n 1000000   -c 10000  (一個php文件)

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

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

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

以上是“優化PHP的案例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！