之所以我要問的是，這個帖子是否有任何基準測試可以顯示Node.js 0.6.8每秒可以處理多少個Comet請求？
http://amix.dk/blog/post/19577
表示Node.js的0.2.2似乎有500/s的門檻，並通過了Netty跑贏10倍。 Ryan Dahl在評論中表示，這可能是因爲後來修復了一個bug。但是，我無法在帖子的其餘部分或其他地方找到任何確認問題已經解決，以及是否更新了基準。我們現在有許多版本超過上面提到的版本，我想知道是否有任何基準，正式或以其他方式與Comet請求/秒有關。
如果沒有基準，最好從總體上了解Amir標記的問題是否仍然存在。 500彗星/秒是一個可以通過適度規模的聊天/遊戲焦點站點到達的門檻。
node.js從0.2.2走了很長的路。在鏈接帖子中討論的架構似乎也可能存在實現問題，因爲評論表明他們沒有考慮在負載平衡器中使用多節點進程。
這顯然是用於高性能應用的必需品 - 事實上，的node.jsofficial about section最後一段寫着：
但對於多處理器並行？不需要將程序擴展到多核計算機的線程？您可以通過child_process.fork（）啓動新進程，這些其他進程將被並行調度。爲了跨多個進程對傳入連接進行負載平衡，請使用羣集模塊現在
，考慮到單個節點0.2.2過程中使用的％10的Netty的資源（如在OP連接柱被提到），然後他們可以在相同的硬件上運行10個節點過程，這引出了一個問題：如果Netty的速度比節點快10倍，但是使用10倍的資源，那麼它們的性能實際上不一樣嗎？同時，在>=0.6.0版本中，節點的性能得到了顯着改善，尤其是在運行Windows的機器上，現在現在支持本機。請參閱Windows基準從0.6.0 release notes：
在HTTP基準是在10GE 網絡從三個負載生成機送達600個客戶做。
v0.4.12 (windows) v0.6.0 (windows)
http_simple.js /bytes/1024 3858 r/s 5823 r/s
io.js read 12.41 mB/s 26.51 mB/s
io.js write 12.61 mB/s 33.58 mB/s
startup.js 152.81 ms 52.04 ms
同時，儘管似乎沒有人想談談正是他們在做什麼，似乎有些流量最大的高科技球員正在轉向node.js極高容量系統。 Google,Yahoo,Mozilla,LinkedIn和啓動i.TV都在風險投資網站昨天發佈的文章Node at scale中進行了描述。
雖然我無法找到確切的彗星基準/秒，似乎很清楚，通過適當的系統架構是多少，多高於500