將套接字服務器從Node.js移植到C＃

Question

我在Node.js中為多用戶人工智能應用程序構建了多個套接字服務器應用程序。 我們正在考慮每盒1K到10K有源插座連接。 然而，即使在空閑和0活動連接時，我的一些服務器在Unix上運行時消耗50-100 MB的內存。 我確信使用像C＃或C ++這樣合理的平台，這應該接近0 MB。 所以我們正在考慮將端口變為“更好”的平台。 現在讓我澄清一下我的用例：

• 這不是“網絡服務器”。 沒有提供文件。
• 我們進行了大量CPU密集型數據處理，某些部分已經移植到C ++並通過本機模塊拉入節點。
• 我們不需要訪問很多I / O（在大多數情況下訪問一些文件，在某些情況下沒有，我們也不使用RDBMS）

我們選擇節點，因為它是Unix友好的（不像.NET），似乎很容易使用。 但是由於目前的內存消耗，我們需要評估其他選項。 許多人將Node.js與ASP.NET進行了比較，但我需要用C＃或C ++構建套接字服務器。

我在.NET和C ++方面有豐富的經驗。 像SuperSocket （由Redgate和Telerik使用）這樣的庫可以處理.NET中的所有低級內容。 我將不得不為C ++找到一個類似的套接字框架。

總而言之，使用.NET或C ++而不是Node.js有什么好處？ 考慮到我的服務器是高度CPU限制的（不受I / O約束）使用.NET / C ++的好處是顯着的還是我應該堅持使用Node.js？ 關於將Node.js應用程序移植到C＃或C ++的任何其他評論？

賞金：我需要C＃和/或C ++中的建議和推薦的套接字服務器庫/實現/示例應用程序。 必須是開源的。 我需要它是高性能，異步和無錯誤。 必須支持二進制數據傳輸。 必須在Windows上運行。 Unix是一個獎勵。

Answer 1

我們正在考慮每盒1K到10K有源插座連接

這里的瓶頸不是編程語言或技術，而是硬件和操作系統支持。 限制並發套接字數量的東西基本上就是你正在運行的機器。 然而，根據我的經驗，C ++的確定對象生存期可以極大地幫助支持大量並發OS資源。

這不是“網絡服務器”。 沒有提供文件。

我在專業工作中做了一些Node.js，我做了一些C＃，但主要是C ++。 即使將node.js作為Web服務器，除了語言本身之外，大多數客戶端和服務器代碼沒有太多共同之處。 Web服務器主要處理商務邏輯，而客戶端處理提取和呈現數據的交互。 因此，我認為node.js作為Web服務器的主要優點在於它為純粹的JS開發人員提供了編寫服務器端的能力，而無需使用他們不熟悉的語言/技術。

我們進行了大量CPU密集型數據處理，某些部分已經移植到C ++並通過本機模塊拉入節點。

是的。 使用強類型語言可以在這里創造奇跡。 沒有redunadand運行時解析。

我們不需要訪問很多I / O（在大多數情況下訪問一些文件，在某些情況下沒有，我們也不使用RDBMS）

嗯，我覺得有一個神話，node.js以某種方式比其他技術更好地處理IO。 這完全是錯的。 Node.js的主要特性是默認情況下IO是異步的。 但Node.js沒有發明任何輪子。 你有Java（又名Java.NIO），C＃（異步/等待）和C ++的異步IO（像epoll / IOCompletionPort這樣的本地東西，或者像Boost.ASIO / CPP-rest，Proxygen等更高級的東西）

我們選擇了節點因為它是Unix友好的（不像.NET）

.Net Core是一種相對較新的技術，其中.Net可以在基於Unix的系統上運行（如linux）

我將不得不為C ++找到一個類似的套接字框架。

Boost.ASIO，或自己寫點東西，真的不是那么難......

總而言之，使用.NET或C ++而不是Node.js有什么好處？

更好的CPU使用率：因為C ++和C＃是強類型語言，而C ++是一種靜態編譯語言，所以編譯器有很大的優勢可以優化CPU廣泛的工作。

較低的內存占用：通常是因為強類型語言具有較小的對象而沒有在場景后面保留大量元數據的開銷。 使用C ++，具有堆棧分配和作用域對象的生命周期通常內存占用率很低。 再次，它取決於任何語言的代碼質量。

沒有回調地獄：C＃有任務和異步等待。 C ++有期貨/承諾，一些編譯器（又名VC ++）確實支持等待。 異步代碼變得非常有趣，因為它與回調相反。 是的，我確實知道JS承諾和新的async / await東西，但與.Net實現相比，它們相對較新。

編譯器檢查：由於必須編譯C＃和C ++，因此在編譯時會遇到很多愚蠢的錯誤。 沒有“undefiend不是函數”或“不能讀取未定義的屬性”。

除此之外，它幾乎是一個選擇問題。

Answer 2

NetMQ是zeromq的本地C＃端口。

Zeromq是輕量級的消息傳遞庫，如果你想了解消息傳遞，zeromq指南是一個很棒的，它也可以作為一本書。 它適用於zeromq和NetMQ。

如果您正在使用Windows並需要處理大量連接，我不建議使用zeromq，因為它不使用IOCP。

NetMQ在Windows上使用IOCP，在Windows和Linux上都可以使用。

披露 - 我是zeromq（libzmq）項目的NetMQ和維護者的作者。

[1] https://github.com/zeromq/netmq

[2] http://netmq.readthedocs.io/en/latest/

[3] http://zguide.zeromq.org/page:all

[4] http://www.amazon.com/ZeroMQ-Messaging-Applications-Pieter-Hintjens/dp/1449334067/ref=sr_1_1?ie=UTF8&qid=1462550951&sr=8-1&keywords=zeromq

Answer 3

我們做了很多CPU密集型數據處理

Node.js從一開始就可能是錯誤的選擇，它可能永遠不會匹配C ++服務器的性能。 但是，如果你做得對，它可能非常接近。 此外，編寫好的C ++並完全重寫系統既困難又耗時。 所以，我想給你一些理由讓你堅持使用Node.js，或者至少在移動之前完全耗盡所有選擇。

我的服務器消耗50-100 MB

你在使用Node.js v0.12嗎？ 使用Node.js v4.2 LTS，空閑Node.js服務器應該使用大約20 MB的內存。 （由於V8，它可能永遠不會接近0 MB）你檢查過內存泄漏嗎？

每盒1K至10K有源插座連接

這應該很容易實現。 如果您使用的是最流行的socket.io庫，這里有一些相關的基准測試。

在使用一個內核的3.3 GHz Xeon X5470上，根據並發級別，每秒​​最大消息發送速率約為9,000-10,000。

來自： http ： //drewww.github.io/socket.io-benchmarking/ （因為，所有這些連接同時保持活動，CPU使用更重要）

如果您已經在使用它並遇到問題，請嘗試使用更快，更具可擴展性的SocketCluster替換socket.io 。 替換它應該比完全重寫更容易。 這是一些基准：

運行Linux的8核Amazon EC2 m3.2xlarge實例

在42K，最繁忙的工作者的CPU使用率下降到45％左右

http://socketcluster.io/#!/performance

最后，證明Node.js幾乎可以達到C ++性能。 看看這個：

服務器使用12G內存

它支持1,200,000個有效的websocket連接

https://github.com/smallnest/C1000K-Servers

我的觀點是，您可以輕松地使用Node.js達到平均性能目標。 嘗試基准測試（ https://github.com/machinezone/tcpkali ）並找到問題而不是完全重寫。