From test data to see performance differences between Node.js and Java EE

The author Marc Fasel is a senior advisor, architect, http://www.aliyun.com/zixun/aggregation/6434.html > software developer. He has 18 years of experience building large, high-performance enterprise apps. In this article, he node.js the test process, results, and conclusions to analyze the performance difference by testing the way in which the test is performed (on a separate performance test on app and Java Server app). (the following are compiled content)
This article compares the performance between Node.js and Java EE by reading JSON data from the COUCHDB. Whose performance is better? To answer this question, only run Node.js app and Java EE app under a series of performance tests to get the final results.
Preparation phase
The first is performance testing on Node.js app and Java server app. Each App uses the same back end as the initial node.js app:couchdb. In addition to this, Couchbase single server version 1.1.3 is used. Create 10,000 random text sample files of size 4KB. The test machine is an imac equipped with 2.4 GHZ, Intel Core 2 Duo, 4 GB RAM, and Mac OS X. In addition, use Apache JMeter as a test drive on a stand-alone machine.
Java EE
The Java server is run on a version of 7.0.21 Apache Tomcat, and the default configuration runs on Java 1.6. The database driver is version 0.30 couchdb4j, and the driver has no caching options, so no configuration has been completed.
The next Java code is a server code that can be couchdb to get the document and process the data as a JSON object.

By using the JMeter test drive to test the server on a different concurrency basis, the following table numbers show different concurrency requirements-the average response time, and corresponding responses per second.

As you can see from the table, the response time changes when parallel requirements are increasing. The response time for each 10 parallel requirements averaged 23 milliseconds, and the response time of 100 parallel requirements averaged 243 milliseconds.
The interesting part is that the average response time is linearly correlated with the number of concurrent requirements, so a 10 times-fold increase in concurrent demand can lead to a 10 times-fold increase in response time for each requirement. This allows for a fairly constant number of processing requirements per second, regardless of 10 concurrent requests or 150 concurrent requests. The number of concurrent service requests that are observed is approximately 420 per second.
Node.js
Node.js APP uses the Cradle couchdb driver version 0.57, which runs in Node.js 0.10.20, and the runtime cache must be closed in order to create equal conditions for the driver.
The next data shows that the Node.js program passes the same JSON document from COUCHDB with a given ID:

The number of Node.js systems is as follows:

As mentioned earlier, the average response time is linearly correlated with the number of concurrent requirements, and the number of processing requirements per second is fairly constant. Node.js is relatively fast 20%, for example, in 10 parallel requirements, 509 requirements/sec vs.422 requirements per second.
Conclusion
Node.js solve the problem faster than Java EE 20%, which is a bit unexpected--an interpretation language and a compiler language in a VM speed is as fast, this is not a multi-year optimization process is absolutely not.
In fact, Node.js and Java EE are larger than normal server requirements. The number of requests per second of 400-500 can be said to be quite good. Google is the world's largest web site, with approximately 5 billion requests per day, or 57,870 requests per second if converted into seconds. This is also the number of Google domain in the world demand, so if you have a running on a machine, 400 demand/sec site, then your site can be said to be quite large. An average of 1 million requirements per day means 11.5 demand/sec. This is a very important figure.
In this performance test, the adoption of a different concurrency model between single-threaded node.js and multi-threaded Java EE has no effect on the final result. If you want to test Node.js performance at a higher concurrency level, you must take into account the issue of the number of open files.