在HTTP模式下，node.js是否比Java有更大的性能优势？
我刚刚开始在node.js中编写一段时间。 这是我的一个问题：
在HTTP应用程序中，给定请求 – 响应模型， 单个应用程序线程被阻塞，直到所有的后端任务完成并且响应返回给客户端，所以性能改进似乎仅限于微调后端事物并行IO请求。 （ 当然，这个改进对涉及到很多繁重和独立的 IO操作很重要，但是通常这个条件也意味着通过重新devise数据结构，可以消除大量的IO请求，并且可能最终获得更好的性能而不仅仅是发行并行操作。 ）
如果那是真的，它怎么会比那些基于Java（或PHP，Python等）的框架产生更好的性能呢？
我也参考了一篇文章了解node.js事件循环 ，这也解释了这种情况：
它确实是一个单线程运行：你不能做任何并行的代码执行; 例如做一个“睡眠”会阻塞服务器一秒钟：
while(new Date().getTime() < now + 1000) { // do nothing } 然而，除了你的代码之外，所有东西都是平行的。
我亲自证实，通过将“睡眠”代码放入一个IOcallback闭包中，尝试提交导致此callback的请求，然后再提交另一个。 两个请求都会在处理时触发控制台日志。 我的观察是，后者被阻止，直到前者回复。
那么，这是否意味着只有在双方都可以随时发送事件和互相推送消息的套接字模式下，才能充分利用其asynchronous处理能力呢？
我对此有点困惑。 任何意见或build议是受欢迎的。 谢谢！
更新
我问这个问题是因为报告了一些性能评估案例，例如Node.js接pipe了企业 – 无论您是否喜欢 ，以及LinkedIn从Rails移动到Node：27服务器的速度提高了20倍 。 一些激进的观点声称，J2EE将被完全取代： J2EE已经死了：由JSON服务支持的长寿命的Javascript 。
据我的经验（虽然简要）与node.js一起，我同意node.js服务器的性能不能与像tomcat等其他web服务器相比，如node.js文档中所述
它确实是一个单线程运行：你不能做任何并行的代码执行; 例如做一个“睡眠”会阻塞服务器一秒钟：
所以我们并不是像tomcat那样只能从tomcat中分离出一些负载，我们可以采用单线程的模式。 所以它必须在某个地方进行折衷
另见http://www.sitepoint.com/node-js-is-the-new-black/那就是关于node.js的美丽文章
NodeJS使用libuv，所以IO操作是非阻塞的。 是的，您的Node应用程序使用1个线程，但是，所有IO请求都被推送到事件队列。 然后当请求发出时，显然它的响应不会在零时间从套接字，文件等被读取。 所以，队列中的任何东西都会popup来处理。 同时，您的请求可以被回答，可能会有大块或全部数据被读取，但是他们只是在队列中等待处理。 这一直持续下去，直到没有事件发生，或者打开的套接字被closures。 然后NodeJS可以终止执行。
如您所见，NodeJS不像其他框架，非常不同。 如果你有一个长期的非IO操作，所以它是阻塞的，就像matrix操作，图像和video处理一样，你可以产生另一个进程并为它们分配作业，使用消息传递，你喜欢TCP，IPC的方式。
NodeJS的主要目的是消除不必要的上下文切换，当使用不当时会带来相当大的开销。 在NodeJS中，你为什么要上下文切换？ 所有的工作被推到事件队列，他们可能是小计算，因为所有他们做多个IO / s，（从db读取，更新数据库，写入客户端，写入裸TCP套接字，从caching读取），阻止他们进入另一个工作是不合逻辑的。 所以在libuv的帮助下，现在可以执行哪个IO就绪。
有关参考请查看libuv文档： http ://nikhilm.github.io/uvbook/basics.html#event-loops
与Java相比，我也注意到了很多关于Node.js性能的激进观点。 从排队理论的angular度来看，我怀疑没有阻塞的单个线程如何执行被阻塞的多个线程。 我想我会自己调查一下Node.js是如何对付更成熟和成熟的技术的。
我通过在Node.js和DropWizard / Java中编写function相同的多数据源微服务来评估Node.js，然后将这两个实现都用于相同的负载testing。 我收集了两次testing结果的性能测量结果，并分析了数据。
在五分之一的代码大小，Node.js有比DropWizard相当的延迟和低16％的吞吐量。
我可以看到Node.js如何与早期创业公司进行合作。 在Node.js中快速编写微服务比使用Java更容易。 随着公司的成熟，他们的重点往往从寻找产品/市场适应转向提高规模经济。 这也许可以解释为什么更多成熟的公司更喜欢使用具有更高扩展性的Java。