錯(cuò)誤代碼確定跟nginx無關(guān)嗎

在CentOS下配置lnmp組合基本上用的都是同樣的配置文件，一直都沒出現(xiàn)過問題，可最近在一個(gè)vps上安裝同樣的環(huán)境之后，網(wǎng)站在線10多人就出現(xiàn)了打開速度非常緩慢的情況，有好幾次都是直接達(dá)到了nginx中設(shè)置的腳本最大超時(shí)時(shí)間300秒，結(jié)果導(dǎo)致nginx往客戶端瀏覽器發(fā)送了一個(gè)504GatewayTime-out的錯(cuò)誤代碼，分析了之后改動(dòng)了幾處配置文件，終于避免了該情況的出現(xiàn)。

從錯(cuò)誤代碼基本可以確定跟nginx本身無關(guān)，主要是提交給php-fpm的請(qǐng)求未能正確反饋而導(dǎo)致，一般情況下，提交動(dòng)態(tài)請(qǐng)求的時(shí)候，nginx會(huì)直接把請(qǐng)求轉(zhuǎn)交給php-fpm，而php-fpm再分配php-cgi進(jìn)程來處理相關(guān)的請(qǐng)求，之后再依次返回，最后由nginx把結(jié)果反饋給客戶端瀏覽器，但我這個(gè)vps目前跑的是個(gè)純php應(yīng)用內(nèi)容，實(shí)際上用戶所有的請(qǐng)求都是php請(qǐng)求，有的耗費(fèi)時(shí)間比較久，php-cgi進(jìn)程就一直都被用滿，而php-fpm本身的配置文件只打開了10組php-cgi進(jìn)程，這樣的話在線用戶稍微多的話就會(huì)導(dǎo)致請(qǐng)求無法被正常處理而出錯(cuò)。

大概分析出了原因，下面做就比較容易了，首先是更改php-fpm的幾處配置：

把max_children由之前的10改為現(xiàn)在的30，這樣就可以保證有充足的php-cgi進(jìn)程可以被使用;

把request_terminate_timeout由之前的0s改為60s，這樣php-cgi進(jìn)程處理腳本的超時(shí)時(shí)間就是60秒，可以防止進(jìn)程都被掛起，提高利用效率。

接著再更改nginx的幾個(gè)配置項(xiàng)，減少FastCGI的請(qǐng)求次數(shù)，盡量維持buffers不變：

fastcgi_buffers由464k改為2256k;

fastcgi_buffer_size由64k改為128K;

fastcgi_busy_buffers_size由128K改為256K;

fastcgi_temp_file_write_size由128K改為256K。

好了，重新加載php-fpm和nginx的配置，再次測(cè)試，至今兩周時(shí)間內(nèi)沒有再出現(xiàn)504GatewayTime-out的情況，算是達(dá)到效果了。

另外，php-fpm的默認(rèn)靜態(tài)處理方式會(huì)使得php-cgi的進(jìn)程長(zhǎng)期占用內(nèi)存而無法釋放，這也是導(dǎo)致nginx出錯(cuò)的原因之一，因此可以將php-fpm的處理方式改成apache模式。

apache-like

從更改完畢到現(xiàn)在的測(cè)試表明上述方式的效果還是很明顯的，并沒有發(fā)現(xiàn)一次Nginx502badgateway或504GatewayTime-out錯(cuò)誤。當(dāng)然，如果你的VPS或者服務(wù)器的性能足夠好可以根據(jù)具體情況不必做無謂的改動(dòng)。