羣集的socket.io服務器掛起

我正在Node.js（6.9.0）中編寫基於socket.io的服務器。我正在使用內置的cluster模塊來啓用多個進程。目前，只有兩個過程：一個主人和一個工人。主站接收連接並維護內存中的全局數據結構（工作人員可通過IPC查詢）。工作進程通過處理每個傳入連接完成大部分工作。羣集的socket.io服務器掛起

我發現一個掛起的情況，當服務器壓力超過300個併發用戶時，我無法歸因於任何內部故障。在較低的併發性下，我沒有看到掛起的情況。

我使所有形式的調試（使用debug模塊：socket.io:socket，socket.io:client以及我自己的自定義調用debug）。

我能看到的最後一個活動是在socket.io，但是，這些消息表明由於它們自己的「測試結束」週期，套接字正在關閉（「reason reason namespace disconnect」）。這看起來好像傳入的連接沒有被服務。

我使用Artillery.io作爲測試客戶端。

在服務器應用程序中，我有一些處理未捕獲的異常和try-catch塊。

在之前的迭代中，我也使用了cluster，但是顛倒了職責，以便主進程處理連接（處理全局數據的工作人員）。這並沒有表現出同樣的失敗。不知道連接分配是否有問題。爲此，我還傾倒了internalMessage事件來監視cluster的內部工作。

我沒有使用任何其他模塊進行連接分配或粘性會話。由於只有一個處理連接的處理（此時），它似乎並不相關。

來源

2017-04-03 gboysko

你是如何通過主從連接的？ – robertklep

我正在使用'cluster'提供的內建機制（據我所知）。實質上，我沒有明確地做任何事情：工作人員創建服務器，初始化'socket.io'，然後只監聽特定的端口。 '集羣'指示該工作人員'聽'呼叫到主人並且路由（通過「循環」）每個新連接到工作人員。 – gboysko

你可以嘗試'cluster'提供的其他方法（參見[this]（https://nodejs.org/api/cluster.html#cluster_cluster_schedulingpolicy），特別是'cluster.SCHED_NONE'），但它也可能是值得的就像暫時禁用查詢主服務器的全局數據結構的工作人員。我認爲只有一名工人是暫時的（一旦這個問題得到解決，可以擴大到多名工人）？ – robertklep

我能夠通過將cluster調度策略從循環法（SCHED_RR）更改爲無，這是操作系統特定的（SCHED_NONE）刪除掛起的條件。我無法分辨這是否是由於連接分配中的錯誤（或調度策略中的其他內在因素），但這一改變似乎可以防止掛起狀況。

來源

2017-04-05 14:53:26 gboysko

羣集的socket.io服務器掛起

回答

相關問題