我有一個現有的服務器應用程序，可以跟蹤網絡上的各種計算機。有時網絡最多可以有6000臺需要跟蹤的計算機。跟蹤涉及到只知道計算機已開機。偶爾服務器會將消息發送回客戶端，需要處理和處理。C＃套接字服務器 - 最大容量和一般問題
我已經嘗試過WCF，但它似乎並沒有很好地處理大負載（當接近1200-2000範圍的客戶端時，CPU使用率很高）;再加上，在WCF中，我必須使它成爲一種「拉」機制，而不是「推」才能將消息發送到客戶端（即客戶端向服務器請求消息）。我正在考慮切換到低級TCP套接字通信，但我不確定期望什麼，這是這個問題的關鍵。
所以：
1 - 有多少客戶端可以我希望能夠連接並保持連接到我的服務器？ 2 - 假設這個連接主要用於讓服務器知道客戶端是否仍然在線，並且從服務器發送非常偶然的消息，我是否可以看到很多資源使用（就CPU/RAM/TCP端口/等）在服務器上？
感謝
看看this bytes.com question關於允許在什麼聽起來像一個類似的情況連接的理論最大數量。
，這似乎是最相關的迴應是：
The magic setting you're looking for is "MaxUserPort". You can google this,
then make the appropriate registry change.
The value is typically set at 5000, and if you want lots and lots of client
connections then you need to bump the value up.
這就是說，你可能會從它是否與您的設計充分混合在本地局域網環境中使用UDP通過TCP受益。我沒有親自在C＃上執行任何基準測試，但已成功支持超過10,000個C++版本的UDP客戶端，並且問題很少（還有一個巨大的盒子）。
我不是兩者之間差異的專家，但它看起來像UDP比TCP更「可靠」;即，如果數據包丟失，它不關心。如果我通過TCP使用UDP，我應該期待什麼？ – bugfixr 2011-12-20 00:16:22
@bugfixr - 當然UDP **可以比TCP更不可靠，但它的開銷也少得多，並且不會跟蹤您的客戶（這可以緩解您在嘗試中遇到的部分問題）。在一個小型局域網環境中，我發現UDP非常可靠。除此之外，您應該通過UDP實施應用協議，以確保可靠性。 – 2011-12-20 00:24:19
1 - 我希望有多少客戶可以連接並保持連接到我的服務器？
5000應該不會有任何問題。
2 - 假設這方面是用來簡單地讓服務器知道如果客戶仍然在線，並從服務器發送一個非常偶然的消息主要級，我會被看到太多的資源使用（在條款CPU/RAM/TCP端口/等）在服務器上？
定義「很多」。打開的TCP連接佔用資源。但最大的資源將是您在BeginReceive中使用的byte[]緩衝區。但讓我們假設它是32768字節大。總共約163Mb。記憶很便宜，不是嗎？
至於CPU使用率，沒有。空閒連接不使用任何CPU。
你真的需要保持這麼多的連接嗎？
這不是因爲您需要對工作站進行「跟蹤」，因此需要建立持久連接。按照您的建議，您可以讓客戶端連接並輪詢一次。其架構上與HTTP有一些相似之處。這樣一個網絡服務器甚至可以滿足你的服務器需求：所有的輪詢客戶端可以被認爲是up，你的服務器可能有話要說，或者它可能沒有。只要你保持連接儘可能短，這並不重要。使用這種方法與放鬆的民意調查結合起來很可能很容易覆蓋上述由一臺服務器「跟蹤」的6000個工作站。
另一種選擇可能是考慮一個消息傳遞基礎結構。服務器發出命令到命令隊列，並且拾取命令的客戶端響應響應隊列。
我猜UDP可以被認爲是實現後者的可能方式。但你必須做更多的工作......
那麼你是否建議有6000個開放的tcp連接將成爲服務器的負擔？比使用WCF更好（順便說一下，我目前使用的WCF按照你所描述的方式進行，因此他們進行了輪詢並因此處於在線狀態，但服務器在2000+客戶端數量下處理不好）。 – bugfixr 2011-12-20 15:20:17
你還沒有真正談到你的問題的時間維度。正如你所說的，問題始於2000年的客戶端門檻。但是我們在說每秒2000個請求，還是2000個持續（開放）連接？後者很容易通過讓每個客戶端在特定的超時時間連接，輪詢和斷開來解決。超時時間越長，您可以跟蹤的「併發」客戶端數量就越高。 – 2011-12-21 08:41:33
你的網絡是一個LAN還是你在談論覆蓋式網絡（通過互聯網）？ – 2011-12-19 23:31:40
99％的時間將是局域網。這是銷售給客戶的產品。 – bugfixr 2011-12-19 23:33:10