Socket.ReceiveAsync可以進入C10K嗎？

Question

使用Socket.ReceiveAsync甚至Socket.SendAsync的TCP套接字能否遇到C10K問題？

Answer 1

我不認為這完全是另一個問題的重復，正如建議的那樣： 高性能套接字上的Async-Await與ThreadPool與MultiThreading（C10k解決方案？）這個問題更多地是關於各種線程模型的討論，並不總是適用於Socket。**** Async（全部使用SocketAsyncEventArgs）。

這個問題的答案在很大程度上取決於您的運行時和操作系統。 我最近在為Unity開發解決方案時走了這條路，所以即使問題有點老，我也將分享我所知道的東西。

讓我們首先討論Windows和MS .NET（實現這些方法時從3.5開始的任何內容）。 在此運行時和平台上組合這些套接字方法時，您肯定可以破壞c10k。 帶有SocketAsyncEventArgs參數的**** Async方法可以直接在運行時中進行本機調用，而本機調用將映射到Windows中的IO完成端口。 這是運行時的特殊路徑，它的作用不只是防止分配IAsyncResult對象。 我認為在Linux上使用.NET Standard的速度也非常快，但是我不能直接這么說。

接下來，讓我們討論Linux上的Mono。 具體來說，我當前使用的是：Mono C＃編譯器版本4.6.2.0這也將破壞c10k，但其工作方式有所不同。 據我所知，***** Async方法在運行時的路徑與所有其他異步方法相同，但**** Async調用的路徑最短，避免了IAsyncResult分配。 運行時通過IOSelector.Add將您的請求作為IOSelectorJob提交。 因此，似乎**** Async方法實際上都不會在Mono中返回false，盡管我不會指望該行為始終為true。 我認為在Windows上使用Mono的速度同樣快，但是我不能這么說。

最后，讓我們談談Unity。 我正在使用具有Mono 5.11.0運行時的2018.3.2f1，設置為.NET 4.x兼容。 我不確定是否可以在Unity中破解c10k。 我不知道為什么，但是我知道在Mono和.NET中輕易破壞c10k的相同實現甚至都不會實現。 我認為這是因為它們的線程池以不同的方式設置了……也許是為了適應他們的工作系統，但這只是一個黑暗的猜測。 發生非常奇怪的事情，例如同步接受優於異步。 永遠不會獲得回調的AcceptAsync請求，依此類推。

在Unity之外打破c10k的一些技巧：-盡可能減少IO完成回調。 不要像MSDN示例一樣在其中調用其他Async方法-如果可以管理，則由於設計原因，不要對SendAsync和ReceiveAsync進行調用彼此阻塞。 您不能使用相同的arg進行2個未完成的調用，但可以同時使用多個和單獨的arg（因此還有緩沖區）進行發送/接收。 但是要注意，排序可能會變得很復雜，例如在同一套接字上有多個未完成的recv的情況下，並發隊列會從回調中調度返回的args-如果必須在線程之間共享資源，則需要使用System.Collections.Concurrent是你的朋友。 不要自己動手，因為這些容器並不是您不破壞c10k的原因，而且您將永遠無法匹配這些嬰兒接受的測試數量

祝你好運，並祝您玩得開心:)如果您發現Unity成功的秘訣，請別忘了告訴我。 如果有的話，我一定會更新。