本文是通过从CouchDB上读取JSON数据来比较Node.js和Java EE之间的性能的。究竟谁的性能更好些？为了回答这一问题，只有在一系列的性能测试下运行Node.js App和Java EE App，才能得出最终结果来。

准备阶段

首先是在Node.js App上和Java伺服器App上分别进行了性能测试。每个App上都是用了相同的后端作为初始Node.js App：CouchDB。除此还使用了CouchBase Single Server版本1.1.3。创造出一万份大小4KB的随机文本样本文件。测试机器是配备2.4 GHZ、Intel Core 2 Duo、4 GB RAM和Mac OS X的iMac。另外，在一个独立的机器上使用Apache JMeter作为测试驱动器。

Java EE

Java伺服器是运行在一个版本为7.0.21的Apache Tomcat上的，默认配置运行在Java 1.6上。数据库驱动程序是版本0.30的CouchDB4J，驱动程序没有缓存选项，所以，没有完成任何配置。

接下来的这个Java代码是一个伺服器的代码，可以通过CouchDB获取文档，将数据作为一个JSON对象来处理。

 

通过使用JMeter测试驱动器来测试伺服器在不同的并发性基础之上，下面的表格数字就展现出不同的并发需求——平均的响应时间，和每秒相应的所对应的回复。

 

从表格里就可以看出，当并行需求在增加的时候，响应时间就会有所变化。每10个并行需求的响应时间平均起来是23分钟，100个并行需求的响应时间平均起来就是243分钟。

比较有趣的部分是，响应时间的平均数和并行需求的数量有着线性相关关系，所以，并行需求增长十倍就会导致每个需求的响应时间增长十倍。这使得在每秒钟处理需求数量是相当恒定的，不管有10个并发请求或150个并发请求，都无所谓。在所有观察到的并发服务请求数量大约为每秒420。

Node.js

Node.js App 使用Cradle CouchDB驱动程序0.57版本，运行在Node.js 0.10.20，为了给驱动程序创造相等的条件，运行时的缓存必须要关闭的。

接下来的数据显示Node.js程序通过一个给定的ID从CouchDB里传递同样的JSON文档：

 

Node.js系统数目如下：

 

正如前面所说的一样，平均的响应时间和并行需求数量呈线性相关关系，每秒钟处理需求数量是相当恒定的。Node.js相对较快20%，例如，在10个并行需求里，509个需求/秒VS.422需求/每秒。

结论

Node.js解决问题的速度比Java EE快20%，这的确有点出乎意料——一种解释语言和一种编译语言在一个VM中的速度是一样快的，这没有多年的优化过程是绝对达不到的。

其实，Node.js和Java EE规模超出正常的服务器需求。每秒400-500的请求数量可以说是相当不错。谷歌是世界上最大的网站，每天有大约50亿个请求，如果换算成秒的话，也就是57870个请求/秒。这也是谷歌域名在世界范围内的需求数量，所以如果你有一个运行在一台机器上的、400需求/秒的网站的话，那你的这个网站可以说是相当的大了。平均每天100万个需求也就意味着11.5需求/秒。这是一个很重要的数字。

在这个性能测试里，在单线程的Node.js和多线程的Java EE之间的采用不同的并发模型对最后的结果是没有影响的。如果想要在更高并发水平里测试Node.js的性能，就必须要考虑到开放文件数量这一问题。