OurJS


OurJS-我们的JS, 我们的技术-IT文摘; 专注JS相关领域;
我们热爱编程, 我们热爱技术;我们是高大上, 有品味的码农;

欢迎您订阅我们的技术周刊


我们会向您分享我们精心收集整理的,最新的行业资讯,技术动态,外文翻译,热点文章;
我们使用第三方邮件列表向您推送,我们不保存您的任何个人资料,注重您的隐私,您可以随时退订,

欢迎分享您的观点,经验,技巧,心得

让我们一起找寻程序员的快乐,探索技术, 发现IT人生的乐趣;


本网站使用缓存技术每次加载仅需很小流量, 可在手机中流畅浏览;
如果您发现任何BUG,请即时告知我们: ourjs(at)ourjs.com

性能测评:Node.JS比Java EE快20%


分享到
分类 大话编程   发布 ourjs  1383230866000
注意 转载须保留原文链接,译文链接,作者译者等信息。  

 

国外某工程师写了一段简单测试脚本,用以比较Java EE和Node.js的性能,结果另他大吃一惊,作为脚本语言的Node.js在竟然比编绎型语言还快了20%,而且还是在不考虑内存消耗的情况下。

他在Mac平台上从CunchDB数据库读取JSON数据,两段测试代码都很短,而且很简单, 代码和结果如下:

Java EE

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();
  }
}

结果

Concurrent Requests

Average Response time (ms)

Requests/second

10

23

422

50

119

416

100

243

408

150

363

411

Node

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);

结果:

Concurrent Requests

Average Response time (ms)

Requests/second

10

19

509

50

109

453

100

196

507

150

294

506

 

原文 :

 

Performance Comparison Between Node.js and Java EE For Reading JSON Data from CouchDB

Node.js has impressed me several times with high performance right out of the box. In my last Node.js project it was the same: we beat the given performance targets without having to tweak the application at all. I never really experienced this in Java EE projects. Granted the project was perfectly suited for Node.js: a small project centered around fetching JSON documents from CouchDB. Still I wanted to know: how would Java EE compare to Node.js in this particular case? 

 

I wanted to know how the performance of the application built on a vanilla Java stack would compare. I ran some simple performance tests. Turns out the Node.js application actually was 20% faster than a similar Java servlet application running on Tomcat 7. Not bad. You cannot generalise these results, though.

The Original Project

The Node.js project had to meet the following performance targets: 150 requests/second at 200ms average response time. I am not a performance guru, 200ms response time sounded pretty fast, and my feeling was that we would have to tweak the application to reach those goals.

A separate team ran performance tests against our application, and when the results came back the application actually had exceeded all performance targets: 200 requests/second at 100ms average response time. That was much better than the targets. I was quite amazed that Node.js was outperforming the requirements by such a margin, and all of this without any performance optimisation.

I asked myself: Is this really a good performance given the functionality of the application? Is Node.js just magically fast? What would the performance be if we would’ve gone with the established platform of Java EE?

I really couldn’t answer that question. Many Java EE applications I have worked on had response times that felt more like 1000ms, but they had more complex functionality than our Node.js application did. The core of our application only pulled out JSON documents by ID from a single table in a CouchDB database. No complex SQL, no table joins, and no data manipulation. I don’t know how a Java EE application would perform given those requirements. So I went out to answer the question: Can the perceived performance of Node.js vs. a traditional Java EE system be backed up by hard performance tests?

To answer this question I designed a set of performance tests to be run against both a Java EE application and a Node.js application, both backed by the same CouchDB database, and looked at how the two systems compared.

Preparation

I ran the the same performance tests against both a Node.js application and a Java servlet application. Both applications used the same backend as our original Node.js application: CouchDB. I used CouchBase Single Server version 1.1.3. I created 10.000 sample documents of 4KB each with random text. The test machine was a iMac with 2.4 GHZ Intel Core 2 Duo, 4 GB RAM, and Mac OS X.

I used Apache JMeter running on a separate machine as a test driver. The JMeter scripts fetched random documents from each application at various levels of concurrency.

Java EE

The Java servlet was run on an Apache Tomcat version 7.0.21, default configuration running on Java 1.6. The database driver was CouchDB4J version 0.30. The driver has no caching options available, so no configuration was done.

The following Java code is a servlet that fetches a document from CouchDB by id and forwards the data as a JSON object.

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();
  }
}

I ran the JMeter tests against this servlet at various levels of concurrency. The following table shows the number of concurrent requests, the average response time, and the requests that were served per second.

Concurrent Requests

Average Response time (ms)

Requests/second

10

23

422

50

119

416

100

243

408

150

363

411

What can be seen is that the response time deteriorates as the number of concurrent requests increases. The response time was 23 ms on average at 10 concurrent requests, and 243 ms on average at 100 concurrent requests.

The interesting part is that the average response time has an almost linear correlation to the number of concurrent requests, so that a tenfold increase in concurrent requests leads to a tenfold increase in response time per request. This makes the number of requests that can be handled per second is pretty constant, regardless of whether we have 10 concurrent requests or 150 concurrent requests. At all observed concurrency level the number of requests served per second was roughly 420.

Node

The Node.js application ran on Node.js 0.10.20 using the Cradle CouchDB driver version 0.57. The caching was turned off for the driver to create equal conditions.

The following shows the Node.js program that delivers the same JSON document from CouchDB for a given ID:

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);

The numbers for Node.js system were as follows:

Concurrent Requests

Average Response time (ms)

Requests/second

10

19

509

50

109

453

100

196

507

150

294

506

As before the average response time has a linear correlation to the number of concurrent requests, keeping the requests that can be served per second pretty constant. Node.js is roughly 20% faster, e.g. 509 requests/second vs. 422 requests/second at ten concurrent requests.

Conclusion

The Node.js is 20% faster than the Java EE solution for the problem at hand. That amazed me. An interpreted language as fast as or faster a compiled language on a VM in which years of optimisation have gone into. Not bad at all.

It is important to take this with a grain of salt: this type of application is perfectly suited for Node.js. I would be weary to extend the findings here to other applications. I believe because of the interpreted nature of JavaScript and the lack of established patterns for programming in the large Node.js application are best kept small.

Both Node.js and Java EE scale beyond what a normal server needs. 400-500 requests per second is quite a lot. Google, the largest website in the world, has about 5 billion requests per day. If you divide that by 24 hours, 60 minutes, and 60 seconds it comes out to 57870 requests/ second. That is the number of requests across all Google domainsworldwide, so if you have a website running with 400 requests per second on one machine your website is already pretty big. 1 million requests per day on average means 11.5 requests per second. Keep that in mind.

In this test the different concurrency models between single-threaded Node.js and multi-threaded Java EE made no difference. To test Node.js at higher concurrency levels – where it is supposed to outshine multi-threading – other problems like the number of open files need to be considered. I was not able to run these tests beyond 150 concurrent users because the OS complained about too many open files. This could have been solved through configuration, but is beyond the scope of this article.

For a general comparison of Node.js and Java EE see my blog Node.js From the Enterprise Java Perspective.

原文地址: 点此
社区评论 ( Beta版 )
  • #0 谢级末 1426646197003

    能不能给个译文,如果js真的那么有前途,我真的想跳出java这个大坑

OnceDoc 您自己的企业内容管理系统——文档、流程、知识库、报表、网盘All In One

访问404页面,寻找丢失儿童
 热门文章 - 分享最多
  1. 为何程序员完成最后20%的工作需要的时间跟之前的80%一样多?
  2. 通过javascript把图片转化为字符画
  3. 一个女软件工程师的征婚PPT
  4. 够用即可:简单之美(Worse Is Better)
  5. 女子发帖赞扬IT男老公 网友纷纷求介绍
  6. 马化腾写代码的水平如何?
  7. 程序员必看的十大电影
  8. 对于现代开发来说,JavaScript就是一种垃圾语言
  9. 做个犀利的码农:如何持续培养/更新自己的开发技能
  10. 性能测评:Node.JS比Java EE快20%
  11. AirJD-简单好用的免费建站工具

 相关阅读 - 大话编程
  1. 盖茨和乔布斯
  2. 程序员遇到bug时常见的30种反应
  3. 《论死亡与临终》中的“库伯勒-罗丝模型”和软件纠错的六个阶段
  4. 个人开发者之死
  5. Javascript诞生记-C和Self语言一夜情的产物
  6. 去他的“工程师逻辑”
  7. 深入理解Atwood定律
  8. Object-C 真是一种啰嗦的语言吗?你怎么看?
  9. 驳PHP优于Node.js的五大理由
  10. Windows XP 有救了

 欢迎订阅 - 技术周刊

我们热爱编程, 我们热爱技术; 我们是高端, 大气, 上档次, 有品味, 时刻需要和国际接轨的码农; 欢迎您订阅我们的技术周刊; 您只需要在右上角输入您的邮箱即可; 我们注重您的隐私,您可以随时退订.
加入我们吧! 让我们一起找寻码农的快乐,探索技术, 发现IT人生的乐趣;


 关注我们

我们的微信公众号: ourjs-com
打开微信扫一扫即可关注我们:
IT文摘-程序员(码农)技术周刊

ourjs官方微信号