么對于nginx，對于php-fpm，backlog應該設置多大，是越大越好嗎？backlog怎么設置合適？這是上篇文章中遺留的幾個問題

接著上篇文章Nginx高并發調優中常被忽略的參數中，最后部分，通過查看nginx源碼發現nginx源碼中定義backlog為511，其實在php-fpm配置文件中，同樣默認backlog是511

包括redis，在默認配置文件中也有backlog配置，默認也是511

其實在redis注釋中已經解釋很清楚了，當你需要處理高并發得場景時，需要較大得backlog來處理堆積得請求，上篇文章對原理已經做了較全面的解釋，網上也有很多大牛關于tcp全連接、半連接的文章講解，今天主要想測試下，backlog在優化設置時，應該怎么設置

為了盡量排除帶寬影響，我這里直接用兩臺內網的機子，一臺作為客戶端用ab去請求，另外一臺作為服務端，服務端是一臺centos7，沒有優化過的系統

首先說一下ss的Recv-Q和Send-Q

在ss命令的結果中，如果該條記錄為監聽端口，則Recv-Q表示accept隊列中元素的個數，Send-Q表示accept隊列中隊列的容量，所以從監聽端口這行正好可以看到隊列的情況

接著開始測試，第一步，先就默認backlog為128的情況下，用ab進行測試

直接開了兩個窗口，用watch執行ss命令，0.1s刷新，在客戶端用ab 200并發請求，開始瞬間php的Recv-Q就滿了(因為我這里nginx連接php用的是socket的方式，所以監聽的是socket，不是端口)，接著查看ab結果

69次失敗請求

查看nginx錯誤日志，69條錯誤日志，都是sock文件資源不可用，如果是用端口的形式，應該是請求超時或連接被重置，這個具體根據php執行時間已經nginx配置超時時間決定

接著調大內核somaxconn，讓somaxconn大于nginx和php的默認backlog，也就是511，這里設置為1024，在接著測試

查看php-cgi的Send-Q，注意這里nginx或者php-fpm都要restart才能生效

接著查看nginx的Send-Q

接著ab進行測試，同時實時查看Recv-Q情況，我先仍然用剛才的ab參數進行測試

截圖有點慢了，打的時候Recv-Q已經到198了，接著快速下降，看下ab測試結果

已經沒有失敗請求了，接著調大ab參數，再進行同樣的測試

手慢了，ab打的瞬間Recv-Q是512，隊列打滿了，接著查看結果，不出意外肯定會有失敗請求

從目前測試的結果來看，最直觀的就是，backlog增大，對于能處理的并發請求來說也在增大，所以backlog優化是必須的，接著繼續增加backlog進行測試

還是用600并發

沒有問題，都能夠正常處理，繼續增加并發到1025

查看結果

接著想看下backlog太大會不會有什么影響，進行如下配置

接著ab測試(測試服務器不一定能扛住，這里ab最大并發2w)

從結果來看，沒有問題，backlog越大越好

但其實這里有個問題，就是我這里測試的只是單php腳本，并沒有涉及到業務代碼，也不查詢數據庫，所以php能夠快速處理，服務器不會崩，那么為什么nginx、php-fpm、redis，都默認設置511，而不設置很大的值，其實在php歷史上，backlog是修改過的(從其他文章看到的)，也是從511，修改到65535，提交者也是認為backlog數量越大越好，即便出現timeout也比syn隊列滿了后，內核忽略掉TCP SYN請求要好

但是在后面又將backlog改回511

其中理由是“backlog值為65535太大了。會導致前面的nginx(或者其他客戶端)超時”，而且提交者舉例計算了一下，假設FPM的QPS為5000，那么65535個請求全部處理完需要13s的樣子。但前端的nginx(或其他客戶端)已經等待超時，關閉了這個連接。當FPM處理完之后，再往這個SOCKET ID 寫數據時，卻發現連接已關閉，得到的是“error: Broken Pipe”，在nginx、redis、apache里，默認的backlog值都是511。故這里也建議改為511

所以我的建議是，用壓測的方法，持續調整測試，取一個適合你業務的最大backlog值，一定要以業務代碼進行測試，而不是單純的調大backlog。

總結

以上是生活随笔為你收集整理的php设置backlog,高并发调优backlog多大合适？的全部內容，希望文章能夠幫你解決所遇到的問題。

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