Node.js和Java EE从CouchDB读取JSON数据的性能比较

ImportNew  •  扫码分享
我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。  
分享到：


本文由 ImportNew - ImportNew读者 翻译自 http://java.dzone.com/articles/performance-comparison-between。如需转载本文，请先参见文章末尾处的转载要求。

【感谢 @北漂IT民工 的热心翻译。如果其他朋友也有不错的原创或译文，可以尝试投递到 ImportNew。】

Node.js出现以来已经给过我几次性能高的印象了。在我上一个Node.js项目中，它的表现一如继往：我们直接超过了设定的性能目标而没有对应用做任何的调整。这是我在Java EE里从未有过的体验。假设这个项目确实是一个为Node.js量身定作的项目：一个主要是从CouchDB读取JSON文档的小项目。但是我还是想知道：JAVA EE在这个案例中跟Node.js比会是一个怎样的表现呢？

这个项目需要达成下面的几个性能目标： 150 请求/秒并具备200毫秒的平均影响时间。 我不是一个性能优化高手，200毫秒的平均影响时间听起来很快，我的感觉是我们可能必须要调节程序以达到些目标。

一个独立的团队针对我们的程序进行了性能测试。测试成绩出来了，结果是程序性能实际上超过了所有设计的性能目标，而是达到到了：200请求/秒， 100毫秒的响应时间。比目标成绩好很多。我相当惊讶,Node.js竟然超于性能需求这么多，并且所有这些不需要任何性能优化。

我又想：这性能对于这种程度的程序来说已经算是好性能了吗？还是Node.js真的就神一样的快？如果我们用Java EE这种成熟的平台来做性能会怎样？

我实在无法回答这个问题。我做过的JAVA EE应用的响应时间感觉更象是在1000毫秒，当然他们比我们这个Node.js应用有更加复杂的功能。我们这个应用的核心只是通过一个ID从CouchDB数据库的一个表里取出JSON数据。没有复杂的SQL,没有表的连接，也没有数据的处理。我不知道一个这样需要的Java EE应用的性能会怎样。所以我继续寻找问题的答案：我所感受到的Node.js对比传统JAVA EE系统的性能是不是可以通过一个严格的性能测试来得到支持呢？

为了回答这个问题，我设计了一套性能测试用例用来对Java EE和Nodejs进行测试，后端采用相同的数据库，并考虑如何去比较这两个系统。

准备

我用同样的性能测试用例来测试Node.js程序和Java Servlet程序。两个程序都使用了与原Node.js程序一样的后端：CouchDB.我使用CoucHBase 单机服务器1.1.3版，并创建10，000个样例文档，每个4KB的随机文本。测试机是一台iMac，2.4G赫兹的Intel Core 2 Duo， 4GB内在，和Mac OS X的系统。

我将一台独立的机器当测试机，并使用Apache JMeter进行测试。JMeter脚本采用不同程度的并发数，向各个程序发起请求，并抓取随机文档。

JAVA EE

JAVA servlet运行在版本为7.0.21的Apache Tomcat之上，默认配置运行在Java 1.6之上。数据库的驱动是CouchDB4J，版本0.30。这个驱动没有缓存选项，所以没有做配置。

下面的Java代码是一个通过ID从CouchDB攻取一个文档并以JSON对象进行转发的servlet。

package com.shinetech.couchDB;

import java.io.IOException;
import java.io.PrintWriter;

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.Log4j.Logger;

import com.fourspaces.couchdb.Database;
import com.fourspaces.couchdb.Document;
import com.fourspaces.couchdb.Session;

@SuppressWarnings("serial")
public class MyServlet extends HttpServlet {
  Logger logger = Logger.getLogger(this.getClass());
  Session s = new Session("localhost",5984);
  Database db = s.getDatabase("testdb");

  public void doGet(HttpServletRequest req, HttpServletResponse res)
    throws IOException {
    String id = req.getPathInfo().substring(1);
    PrintWriter out = res.getWriter();
    Document doc = db.getDocument(id);
    if (doc==null){
      res.setContentType("text/plain");
      out.println("Error: no document with id " + id +" found.");
    } else {
      res.setContentType("application/json");
      out.println(doc.getJSONObject());
    }
    out.close();
  }
}

我运行JMeter对这个servlet进行了不同并发的测试。下面的表示显示了并发数，平均影响时间，每秒请求数。

并发数

平均影响时间(ms)

每秒请求数

10

23

422

50

119

416

100

243

408

150

363

411

我们可以看到响应时间随着并发数的增长不断的恶性延长。在10个并发时是23毫秒，而在100个并发时变成是243毫秒。

 

一个有意思的情况是平均响应时间几乎与并发数是呈线性相关的，所以一次10倍增长的并发请求会导致一个10倍增长的响应时间的增长。这样就说明每秒能处理的请求数是一个相当固定的值，不管我们有10个并发请求，还是150个并发请求。不管是什么样的并发情况，服务器每秒钟处理的请求数大约是420个。

Node

Node.js程序运行在Node.js 0.10.20之上，使用Cradle的CouchDB驱动，版本是0.57，并为了环境的一致缓存被并掉。

下面的Node.js代码实现对于一个给定的ID给从CouchDB里取出的同样的JSON文档的功能：

var http = require ('http'),
  url = require('url'),
  cradle = require('cradle'),
  c = new(cradle.Connection)(
          '127.0.0.1',5984,{cache: false, raw: false}),
  db = c.database('testdb'),
  port=8081;

process.on('uncaughtException', function (err) {
  console.log('Caught exception: ' + err);
});

http.createServer(function(req,res) {
  var id = url.parse(req.url).pathname.substring(1);
  db.get(id,function(err, doc) {
    if (err) {
      console.log('Error'+err.message);
      res.writeHead(500,{'Content-Type': 'text/plain'});
      res.write('Error' + err.message);
      res.end();
    } else {
      res.writeHead(200,{'Content-Type': 'application/json'});
      res.write(JSON.stringify(doc));
      res.end();
    }
  });
}).listen(port);

Node.js下得到的数字如下：

并发数

平均影响时间(ms)

每秒请求数

10

19

509

50

109

453

100

196

507

150

294

506

同之前的平均响应时间一样，它与并发数有一个线性的关系，证实了每分钟可以处理的请求数是一个相当恒定的值。Node.js约快出20%。 如在10个并发时，每秒请求数分别为509 vs 422。

结论

Node.js对于当前的任务来说，相比于JAVA EE要快出20%。这对我来说很震惊。一个解释型语言与一个建立在历经多年优化的VM之上的编译弄语言相比竟然速度能保持在一个水平上。相当的赞！

但是我们必须要认识到这个结论是受条件限制的：这种类型的程序是Node.js所擅长的。我担心将这个结论应用到其它类型的程序上可能会不成立。我认为由于Javascript是解释型语言，并且缺少成熟的面向大型Node.js应用的开发模式，所以Javascript程序最好保持较小的规模。

Node.js与Java EE的服务能力是超过正常的服务器需求的。400~500每秒的请求数是相当大的。世界上最大的网站Google有大约50亿次请求每天。如果你用24小时，60分钟，50秒来分这些请求，那么它的结果是57870个请求每秒。这就是Google全球所有域名的请求数。所以如果你有一个请求在400每秒种的网站在一台机器上，那么你的网站已经非常大了。100万请求每天平均下来就是11.5请求每秒。请牢记。

在这个测试中，不同的并发模型，不管是单线程的Node.js还是多线程的Java EE，差别不大。为了测试Node.js在更大的并发量时的表现–这个通常会被认为强于多线程的地方，象打开的文件数限制之类的问题是需要被考虑到的。我不能产生150个以上的用户来并发测试是因为OS已经因为打开文件过多而报错了。这个可以通过配置解决，但已经不在本文的讨论之内了。

 

a

-- 扫描加关注，微信号: importnew --
原文链接： http://java.dzone.com/articles/performance-comparison-between 翻译： ImportNew.com - ImportNew读者
译文链接： http://www.importnew.com/6817.html
[ 转载请保留原文出处、译者、译文链接和上面的微信二维码图片。]



可能感兴趣的文章

  • 5种调优Java NIO和NIO.2的方式
  • Eclipse 4 新手上路
  • JVM性能优化， Part 3 垃圾回收
  • 下一代大型JVM语言
  • 通过Google Play验证Android应用的后台请求
  • HBase数据迁移（2）- 使用bulk load 工具从TSV文件中导入数据
  • Google I/O 2013隆重推出Android Studio （含下载地址）
  • Oracle WebLogic Server 12.1.2发布
  • Apache HBase 快照介绍之二：深入探索
  • 5本最佳的Java面向对象理论和设计模式的书籍

随意打赏

提交建议
微信扫一扫，分享给好友吧。
关闭