我问的原因是这篇文章
http://amix.dk/blog/post/19577
表示Node.js 0.2.2似乎具有500 / s的阈值,并且表现优于Netty的10倍。在评论中,Ryan Dahl表示可能是因为一个随后被修复的错误。但是,我无法在帖子的其余部分或其他地方找到任何确认问题得到解决以及是否更新的基准测试。我们现在比上面引用的版本更多版本,我想知道是否有任何基准,正式或其他与Comet请求/秒有关。
如果没有基准测试,那么一般来说,了解Amir标记的问题是否尚未完成将是一件好事。 500彗星/秒是一个门槛,可以通过适度规模的聊天/游戏网站来达到。
答案 0 :(得分:2)
node.js
离0.2.2
还有很长的路要走。在链接帖子中讨论的体系结构似乎也存在实现问题,因为评论表明他们没有考虑将多个节点进程与负载均衡器一起使用。
这显然是高性能应用程序的必需品 - 实际上,node.js
official about section的最后一段是:
但是多处理器并发呢?将程序扩展到多核计算机不是必需的线程吗?您可以通过child_process.fork()启动新进程,这些其他进程将并行调度。对于跨多个进程的传入连接的负载平衡,请使用群集模块。
现在,考虑到单个节点0.2.2
进程使用了Netty资源的%10(如OP链接帖子中所述),那么他们可以在同一硬件上运行10个节点进程问题:如果Netty比节点快10倍,但使用10倍的资源,那么他们的性能实际上是不是相同?同时,节点的性能在>=0.6.0
版本中得到了显着改善,尤其是在运行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
极高容量系统。昨天在venturebeat.com上发布的文章Node at scale中分析了Google
,Yahoo
,Mozilla
,LinkedIn
和启动i.TV
。
虽然我找不到彗星/秒的确切基准,但似乎很清楚,通过适当的系统架构,它很多,很多高于500.