在連接請求和性能問題之間傳播等待時間

Question

我開發了一個基於帶Netty的tcp/ip-stack自定義協議的服務器。寫這個很愉快。

現在我正在測試性能。我在netty上編寫了一個測試應用程序，它只需連接大量（20.000+）「客戶端」到服務器（在每次引導連接後使用Thread.wait（1）for循環）。一旦連接了一個客戶端通道，它就會向服務器發送一個登錄請求，該請求會檢查該帳戶併發送登錄響應。

整體表現似乎相當不錯。所有客戶都在60秒以內登錄。但不好的是每個連接的等待時間。我有非常快速的登錄和極慢的登錄。在整個測試時間內，變化範圍從9ms到40,000ms。是否有可能在請求的頻道（Fifo）之間共享等待時間？

我測量了很多重要的時間戳，發現了一個奇怪的現象。我有很多連接，其中服務器的「通道連接」時間戳在客戶端的時間戳之後（最長爲19秒）。我也有「正常」的情況，他們匹配，只是客戶端發送和服務器接收之間的時間是幾秒鐘。在這兩種情況之間都有一些情況。怎麼可能，客戶端和服務器「通道連接」是相距太遠的時間？

可以肯定的是，客戶端立即在發送後立即收到服務器的登錄響應。

調整： 我想我讀了大部分表現文章在這裏。我在4CPU-Hyper-Threading-i7上使用帶有200個線程的OrderMemoryAwareThreadPool作爲傳入連接，並且還使用已知的激進選項啓動服務器應用程序。我也完全調整了我的Win7-TCP-Stack。 服務器在我的機器上運行非常流暢。 CPU使用率和內存消耗是ca.在50％以上可以使用。

太多的信息： 我還從2個獨立的機器中啓動了2個測試應用程序，每個機器以15000個連接「並行攻擊」服務器。在那裏，我有大約800個連接從服務器獲得超時。這裏有什麼意見？

最好的問候和歡呼聲給了Netty， 馬丁

Answer 1

的Netty有一個專門的老闆線程接受傳入連接。如果boss線程接受新的連接，它將連接轉發給工作線程。由於這個原因，接受和實際套接字讀取之間的等待時間可能會大於預期負載。雖然我們正在研究改善情況的不同方法，但同時，您可能希望增加工作線程數，以便工作線程處理更少的連接數。

如果您認爲它的表現比非Netty應用程序差，請隨時與file an issue一起復制測試用例。我們將嘗試重現並解決問題。