Nginx下請求本機另外Host很慢怎么辦

這篇文章給大家分享的是有關(guān)Nginx下請求本機另外Host很慢怎么辦的內(nèi)容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

現(xiàn)象

在本機安裝了一個Discuz!X3.4的論壇，其使用UCenter作為統(tǒng)一用戶登錄，在其應(yīng)用管理頁面，通信情況一直提示為“正在連接”：

原因

關(guān)于這個問題，網(wǎng)上絕大多數(shù)的說法是nginx服務(wù)器在Windows上有問題，建議更換為Apache，我更換到Apache下，也確實是問題解決了，但是我還是覺得nginx不至于有這種問題，一定有解決的辦法。

再繼續(xù)查找，發(fā)現(xiàn)nginx日志里有報告499錯誤，網(wǎng)上說499錯誤的原因是客戶端主動斷開了與服務(wù)器的連接，可是看ucenter的代碼，貌似并沒有斷開連接的操作，倒是看日志報告的時間，發(fā)現(xiàn)一點端倪：

第1行日志，是ucenter應(yīng)用管理中心頁面的鏈接，在這個頁面里，ucenter向本機的Discuz服務(wù)器發(fā)出通信驗證請求（第3行日志），而第2行日志，就是Discuz服務(wù)器收到的通信驗證請求，499錯誤就是出現(xiàn)在此行。

仔細查看這3條日志的時間，發(fā)現(xiàn)第2、3條與第1條間隔差不多29秒，我們知道，PHP默認的超時時間為30秒，算上點誤差，29秒也差不多。因此可以認為這個499錯誤是因為ucenter服務(wù)器發(fā)起了ping請求（第3行日志），一直沒有接收到返回值，結(jié)果超時斷開連接，從而導致discuz服務(wù)器出現(xiàn)499錯誤。

整個流程如下圖：

知道是499錯誤，于是又查找如何解決499問題，結(jié)果大多數(shù)提出要在nginx服務(wù)器中添加如下配置：

在Discuz的配置項中添加了上述配置：

再運行服務(wù)器，發(fā)現(xiàn)499問題果然沒了，但是通信問題依然沒有解決，只是日志變?yōu)槿缦铝耍?/p>

配置生效了，但是有個毛用啊，通信還是不成功。第1條日志和下面兩條日志還是差了差不多30秒左右。回過頭來仔細分析上面的兩個配置項，應(yīng)該是讓nginx服務(wù)器忽略客戶端斷開的錯誤，注意，僅僅是讓服務(wù)器忽略這個錯誤，也就是說，當ucenter請求超時，斷開連接的時候，discuz服務(wù)器忽略了這個錯誤，從而返回200，可是ucenter實際上已經(jīng)斷開了，也收不到discuz的返回值，所以實際上還是通信失敗。

不過再進一步分析上面的流程，從nginx與php的關(guān)系來看，發(fā)現(xiàn)整個請求處理如下圖：

nginx收到請求后，發(fā)現(xiàn)是需要執(zhí)行PHP代碼，于是將請求就轉(zhuǎn)給了PHP-CGI進程，由該進程找到PHP代碼并執(zhí)行，但是在PHP代碼中，又再次向本機的另一個服務(wù)器發(fā)出HTTP請求，nginx收到后，發(fā)現(xiàn)同樣要執(zhí)行PHP代碼，于是將請求又轉(zhuǎn)回給PHP-CGI進程，但是系統(tǒng)中PHP-CGI進程只開了一個，后面的PHP代碼要等到上面的執(zhí)行完畢才能執(zhí)行，而后面的PHP代碼卻又是上面的代碼請求產(chǎn)生的，于是就阻塞了。

1.1.3  解決

分析至此，解決的思路就已經(jīng)很清晰了，既然一個PHP-CGI線程處理不過來，那么就增加一個線程好了，修改啟動nginx服務(wù)器的批處理代碼如下，僅修改一個數(shù)字，見紅色字體部分：

該數(shù)字原來是1，現(xiàn)在改為2，重新啟動服務(wù)器，看任務(wù)管理器，果然有兩個PHP-CGI進程：

再回到ucenter的應(yīng)用管理頁面，刷新，結(jié)果如下：

啥情況？我們上面折騰了半天，只是從“正在連接”變成了“通信失敗”，問題還是沒有解決?。?/p>

不過呢，跟蹤代碼可以驗證，499的問題的確是徹底解決了，至于為什么還是“通信失敗”，那是另外一個問題了。

感謝各位的閱讀！關(guān)于“Nginx下請求本機另外Host很慢怎么辦”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！