在HTTP模式下,node.js是否比Java具有显着的性能优势？

Question

我刚刚开始在node.js中编写代码一段时间.现在,这是我的一个问题:

在HTTP应用程序中,给定请求 - 响应模型,单个应用程序线程被阻塞,直到所有后端任务完成并且响应返回给客户端,因此性能改进似乎仅限于微调后端事务,如微调并行化IO请求.(当涉及到涉及许多繁重且独立的 IO操作时,这种改进很重要,但通常条件还意味着通过重新设计数据结构,您可以消除大量IO请求,并可能最终获得更好的性能而不仅仅是发布并行操作.)

如果这是真的,那么它怎么能比那些基于Java(或PHP,python等)的框架产生更好的性能呢？

我还提到了一篇文章了解node.js事件循环,这也解释了这种情况:

它实际上是一个单线程运行:你不能执行任何并行代码执行; 例如,进行"休眠"将阻止服务器一秒钟:

while(new Date().getTime() < now + 1000) {
   // do nothing
}

...但是,除了你的代码之外,一切都是并行的.

我个人验证了通过将"睡眠"代码完全放入一个IO回调闭包,并尝试提交导致此回调的请求,然后提交另一个.两个请求在处理时都会触发控制台日志.我的观察是后者被阻止,直到前者回复了一个回复.

那么,它是否意味着只有在套接字模式下,双方都可以随时发送事件并相互推送消息,是否可以充分利用其异步处理能力？

我有点困惑.欢迎提出任何意见或建议.谢谢!

更新

我问这个问题是因为报告了一些性能评估案例,例如Node.js正在接管企业 - 无论你喜欢与否,LinkedIn从Rails迁移到节点:27台服务器切割速度提高了20倍.一些激进的观点声称J2EE将被完全取代:J2EE已死:由JSON Services支持的长期Javascript.

Answer 1

NodeJS使用libuv,因此IO操作是非阻塞的.是的,您的Node应用程序使用1个线程,但是,所有IO请求都被推送到事件队列.然后,当发出请求时,很明显它的响应将不会在零时从套接字,文件等中读取.因此,弹出队列中准备好的任何内容并进行处理.同时,可以回答您的请求,可能有要读取的块或完整数据,但是它们只是在队列中等待处理.这种情况一直持续到没有事件遗留,或者打开的套接字关闭.然后NodeJS最终可以结束执行.

如您所见,NodeJS与其他框架不同,非常不同.如果你有一个漫长的非IO操作,所以它是阻塞的,如矩阵操作,图像和视频处理,你可以产生另一个进程并为它们分配作业,使用消息传递,你喜欢TCP,IPC的方式.

NodeJS的主要目的是删除不一致的上下文切换,如果使用不当会带来很大的开销.在NodeJS中,您为什么要上下文切换？所有作业都被推送到事件队列,它们的计算量可能很小,因为他们所做的只是做多个IO/s,(从db读取,更新db,写入客户端,写入裸TCP套接字,从缓存读取),将它们停在中间并切换到另一个工作是不合逻辑的.因此,在libuv的帮助下,任何准备就绪的IO都可以立即执行.

如需参考,请查看libuv文档:http://nikhilm.github.io/uvbook/basics.html#event-loops

Answer 2

就我使用node.js的经验（虽然简短）而言，我同意node.js服务器的性能无法与其他网络服务器（如tomcat等）进行比较，如node.js文档中所述

\n\n

\n

它实际上是一个正在运行的线程：您可以\xe2\x80\x99t执行任何并行代码\n；例如，执行 \xe2\x80\x9csleep\xe2\x80\x9d 将阻止服务器一秒：

\n

\n\n

因此，我们不是用它来替代像 tomcat 这样成熟的网络服务器，而只是为了分散来自 tomcat 的一些负载，我们可以在其中采用单线程模型。所以必须在某个地方进行权衡

\n\n

另请参阅http://www.sitepoint.com/node-js-is-the-new-black/那是关于 Node.js 的精彩文章

\n