以前公司網站架構一直都是nginx+apache，因為apache市場占有率還是很大的，穩定性也一直很好，加上如今版本已經升級到2.4，安全和性能方面都有提升，因為公司業務訪問量不是太大，所以一直也沒計劃更換，但最近因為測試人員用jmeter連續測壓測3輪200并發（壓測都是動態請求）反饋很多報錯，查了一個apache的錯誤日子，報內存不夠，8G的內存應該不會這么差吧！而且響應時間在我看來也比較久，其中當然也有一些代碼的原因，這里我只想從運維的角度去試試php-fpm替代apache看看效果如何？其實說白了最后主要就是看響應時間和錯誤率。
1、首先保存單臺apache（kvm運行，apache還是優化了的）的壓測數據（總共29個接口）


再看看apache優化之后的參數

2、因為這次在測試swarm mode，所以正好通過swarm部署php-fpm環境，單臺docker容器運行，代碼一樣，php.ini版本和參數基本都一樣，下面看一組www.conf基本沒有做任何優化的壓測結果

分析nginx日志和壓測結果看到很多500錯誤，當時我就納悶了，php-fpm不至于這么弱吧？不是高并發的網站都是使用php-fpm嘛！當時查了一下php-fpm日志報錯如下：
Failed to connect to redis: Cannot assign requested address
經排查是php-fpm服務端連接redis有問題，php-fpm頻繁的連redis服務器，由于每次連接都在很短的時間內結束，導致產生太多的TIME_WAIT不釋放，以至于用完了可用的默認端口號，所以新的連接沒辦法綁定端口，說明是php-fpm服務端的問題，而不是redis服務器端的問題。通過netstat的確也看到很多TIME_WAIT狀態的連接，所以我們需要簡單的做一些內核參數優化。
解決辦法：
在docker容器所在的宿主機上執行命令
sysctl -w net.ipv4.tcp_timestamps=1 開啟對于TCP時間戳的支持,若該項設置為0，則下面一項設置不起作用
sysctl -w net.ipv4.tcp_tw_recycle=1 表示開啟TCP連接中TIME-WAIT sockets的快速回收
再次壓測已經看到沒有500錯誤，也就是錯誤率為0，響應時間和apache不分上下，有的接口高，有的接口低，雖然相差不是很大，但這只是php-fpm參數沒有優化壓測的結果，已經讓我感到一絲絲的欣慰啦！
下面是響應時間的截圖對比

關于php-fpm優化壓測的細節和結論
對于www.conf優化并不是設置的進程數量越高越好，如果設置不合適就會導致系統負載很高，也需要根據壓測結果和php-fpm報的錯誤日志需要不斷的調試和壓測，提一句還是看結果最重要。下面是我壓測過程中日志警告的截圖


下面是我調優的參數，系統負載最高都能到30左右。其實還是建議大家根據實際的硬件配置優化，這里我限制了CPU能使用宿主機的400%，內存8G。一般一個php-fpm占用20M內存左右。
www.conf主要優化參數：
php-fpm工作模式選為默認，如果內存很大可以設置為static，但是設置static后只有pm.max_children一個參數有效（切記切記），設置dynamic是所有參數都有效，另外還有一種ondemand管理方式，這里不多議。
www.conf文件優化如下：
pm = dynamic
子進程最大數
pm.max_children = 50
優化后為100，因為并發是200，持續3輪，理論上一般并發多少這個值就設置多少，然后相對于的增加一點點即可！這樣php-fpm日志就不會報最大子進程數不夠的警告。比如這里我壓測的時候也設置了300，觀察了php-fpm最多250個左右子進程，但是設置為300的響應時間還沒有100好看。
初始子進程數
pm.start_servers = 5
優化后為50
最小空閑子進程數
pm.min_spare_servers = 5
優化后為50
最大空閑子進程數
pm.max_spare_servers = 35
優化后為70
每個子進程重生之前服務的請求數
pm.max_requests = 500
優化后為4000
單個請求的超時中止時間
request_terminate_timeout = 0
優化后為10，如果后端處理時間大于10秒就會報出502，這也是為了很好釋放資源的優化，設置的時候一定要注意。
文件打開描述符的rlimit限制
rlimit_files = 1024
優化后為8192
再次壓測結果響應時間php-fpm還不如apache好看，甚至比apache弱，這一點確實讓我很驚訝，關于www.conf配置文件我優化了N次，但是壓測結果在處理時間都沒讓我很滿意，雖然在錯誤率這方面優勢很明顯，難道只是我一廂情愿的認為php-fpm比apache強很多嗎？難道對于我這種壓測標準默認的配置就是最優的嗎？這里結果是單臺php-fpm只是在錯誤率上面有明顯的優勢，處理時間上如果優化不好會比apache弱或者不分上下？以后準備拋除所有壓測php測試頁面進行對比看看！
個人疑問：
1、最大子進程數設置很大，系統負載偶爾會飆升很高，甚至有時候能到一百多，這里讓我很不解。
2、當top看到系統負載不高，而vmstat查看r列會造成cpu嚴重不足，也能到一百多，又讓我真心有點不理解了。

總結

以上是生活随笔為你收集整理的关于对php-fpm的压力测试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。