隨著php腳本語言使用的普及，目前webserice服務大部分都在用nginx+(php-fpm)的結構，了解了其工作過程后才可以在各個方面想辦法做調整優化和故障排查，從以下幾點總結一下這種模型。
一、nginx和php-fpm的關系和分工
nginx是web服務器，php-fpm是一個PHPFastCGI進程管理器，兩者遵循fastcgi的協議進行通信，nginx負責靜態類似html文件的處理，php-fpm負責php腳本語言的執行，這么設計的目的是為了解耦前端nginx和后端的php，不至于讓容易出問題的php腳本堵塞整個nginx的業務處理，影響用戶體驗，因為php腳本語言的執行是會比較容易出問題的。nginx之所以能處理成千上萬高并發業務，除其本身的異步非阻塞模式，在與和其他模塊的耦合擴展方法也是分不開的，在nginx的設計里不能接受的就是阻塞，不過并非完全沒有梗，比如說用到的最多的多進程單線程的模式，由于nginx日志沒有單獨的處理進程，如果收集日志時處理不當就會把worker進程堵死。
對應nginx+php-fpm的模型結構圖如下：
1、nginx的工作簡介
接到php的腳本請求后，nginx通過fastcgi_pass指令將請求傳遞給后端php-fpm的worker進程處理，在此過程中，nginx做了各種超時機制、緩存機制、buffer機制和長連接機制等來保障與后端的php-fpm能夠良性高效的合作。
在超時機制方面控制nginx對后端php的等待時間，通過各種timeout指令進行控制，例如：
fastcgi_connect_timeout ： ?后端鏈接時間
fastcgi_send_timeout ?： ?數據發送時間，兩次成功發送時間差，不是整個發送時間
fastcgi_read_timeout ?： ?數據接收時間，兩次成功接收時間差，不是整個接收時間
當超時后會返回504超時的狀態碼，在buffer機制指令也有很多，例如：
fastcgi_buffer_size 存放fastcgi傳過來的響應頭，一般設置為分頁大小
fastcgi_buffers 存放fastcgi傳過來的相應內容，一般設置分頁的倍數，格式例如 8 ?4k|8k
另外還有一些其它的緩存、長連接機制不做介紹，當設置不合理時也會出現5XX錯誤，nginx的文章介紹寫了有很多的，不再做過多的說明。
2、php-fpm工作介紹
Php-fpm是一個PHPfastcgi進程管理器，在啟動后會有master和worker兩種進程，master負責接收外部信號和管理worker進程，worker進程是負責干活的，處理nginx傳過來的任務。
master進程只有一個，負責監聽端口和管理worker進程，每次傳來任務，與前端的nginx建立3次握手后放入連接隊列，供worker進程進行accept，當worker進程出現錯誤或執行超時時，負責將worker進程重啟或者殺掉，是php-fpm模型中的大內總管。
Worker進程是工作進程，每個worker進程都獨立的執行php程序腳本，然后把執行的結果通過fastcgi協議交給nginx，執行過程中受master的管理。在工作中，worker進程去競爭accept管理進程master的鏈接隊列，accept函數將從連接請求隊列中獲得連接信息，創建新的socket，并返回該套接字的fd，新創建的socket用于服務器與nginx的通信，而原來的套接字仍然處于監聽狀態。
php-fpm可以配置多個pool，所有pool由master統一管理監聽不同端口并分配不同worker進程池，worker進程池支持動態prefork同時也支持靜態開啟，服務器內存較大時建議直接計算后配置靜態資源池，可以減少頻繁prefork進程所帶來的開銷，提高服務質量，由于進程模型越跑程序耗費越大，因為每個worker進程可以配置執行多少個請求后進行重啟，對應的池子的指令和執行多少個請求的指令如下：
pm = static | dynamic | ondemand ：靜態池、服務優先、內存優先
pm.max_children = 256 ?： 開啟的最大php進程數
pm.max_requests = 1024 ?： 在執行了1024個請求后重啟worker進程
這也是我們線上服務器的配置，我們線上用的web服務的機器是12核cpu、16G內存，nginx開啟12個worker進程，php開啟256個進程，跑起來后每個進程大概占用30M內存，也就是（256+12）*30=8G ，另外還跑了一些配管、監控、統計、日志收集等七七八八的軟件，整體業務是比較輕松的，這種靜態池的配置大大減少了prefork進程帶來的開銷，RT時間100ms以內的占到90%以上（這個與程序寫的如何有關），運行一段時間后的開銷截圖如下：
二、此模型結構常見的5XX
服務器端錯誤及優化
1、nginx日志里產生502錯誤
第一種情況，php-fpm的worker進程執行php程序腳本時，超過了配置的最長執行時間，master進程將worker進程殺掉，直接返回502。返回502后nginx對應的error日志是104: Connection reset by peer,對應的php執行時間的配置如下，一些版本中php-fpm的配置會覆蓋php.ini的配置，使php.ini的配置不起作用：
php.ini中默認30s：max_execution_time =
php-fpm中：request_terminate_timeout =
第二種情況，連接請求數（accpet之前）超出了端口所能監聽的tcp連接的最大值（backlog的值），進不了fpm等待accept的鏈接隊列，直接返回502，這里可能會產生tcp重傳；返回502后nginx對應的error日志是111: Connection refused, backlog的值是半連接和全連接的總和，他的存在也有短時間緩沖解耦nginx請求與fpm處理的作用，半連接指收到了syn請求，3次握手尚未建立，全連接指的是3次握手已經成功，不過尚未被accpet的請求，fpm里面有調節的參數，如果fpm的參數設置為-1，則默認走的是系統內核參數net.core.somaxconn的設置值，如果不設置可以在/proc/sys/net/core/somaxconn里查看，默認值是128，所以在連接請求較高的業務里要增大這個值。
第三種情況，網絡卡時，客戶端斷開連接，nginx處顯示499，然后php檢查到前端nginx產生abort后，又master結束此條任務的繼而產生502，一般此種情況的報警，先是499，過會兒變成502，再過一會變成504.
減少避免502報錯優化建議
502主要從php-fpm的配置方考慮，根據服務器情況，適量增大php-fpm的工作進程數，適當增加php的執行時間，適當增加backlog值。
php的工作進程數也不是越大越好，這種進程模型運行時間長了占的內存會增大，一般一個php進程是占到30M左右的內存，開多少合適自己算吧，nginx的worker進程一般也能跑到30M的內存，綜合計算一下；php的執行時間可以根據你的服務標準來設定，超過服務時間瀏覽器返回的是502錯誤，這個按照實際的情況處理吧，反正我是覺得執行的慢有返回結果總比直接返回502錯誤的強；至于backlog值，當程序寫的比較好時，建議設置其數量為php工作進程的1到2倍。
2、nginx日志里產生504錯誤
第一種情況，php的worker進程池處理慢，無法盡快處理等待accept的鏈接隊列，導致3次握手后的鏈接隊列長時間沒有被accept，nginx鏈接等待超時；返回504后nginx對應的error日志是110: Connection timed out
第二種情況，后端php-fpm執行腳本的時間太長，超過了nginx配置的超時機制，這個時候也是會報出504錯誤的。
第三種情況，客戶端的網絡及其差，php將請求處理完交給nginx后，nginx沒能在超時時間內將內容全部吐給用戶，這時也會超時，只有504而沒有502。
減少避免504報錯的優化建議
504主要從nginx的配置方考慮，根據業務情況配置好超時的各種機制，包含但不限于下屬參數：
fastcgi_connect_timeout
fastcgi_send_timeout
fastcgi_read_timeout
另外：在配置過程中，比如遇到大并發或者是特殊業務的場景，不合理的fd、buffer等設置也會帶來5XX錯誤，比如說大并發連接的業務要增大系統和單個程序的fd數量，如果是上傳業務要增大頭buffer等，這些要視情況而做優化，正所謂道法自然，術變萬千，要以不變應萬變。
