Verify the HTTP Module performance comparison test for Golang and node. JS again

This is a creation in Article, where the information may have evolved or changed.

Previously seen in the performance comparison test article, is about node. js and Golang HTTP module, simple HelloWorld function, the original text in this:

http://www.cnblogs.com/QLeelulu/archive/2012/08/12/2635261.html#2447171

After this article, node. js and Golang are upgraded, node. JS is now 0.10, and Golang is in version 1.1, so I suddenly want to do a performance test on the basis of our predecessors.

The specific code still follows the references in the article.

Hardware: Dual CPU, model Xeon E5620 2.40GHz, 4-core CPU, because Hyper-threading is supported, so the system displays a logical CPU count of 16.

Software Environment: centos6.0. The node. JS version is 0.8.15 and is not using the newest 0.10.13 now. Golang for the newest 1.1. Both are not equivalent from the old and new versions, but in the end I will upgrade the node. js version to compare.

test Tool: Apache AB, test parameters are concurrent 1000, complete the total is 200,000 times.

node. JS completes requests per second under the 1.2.4,8,16 process:

5980

11300

15495

20435

21029

The following data are supported by the Golang in the corresponding core number:

11109

16477

21874

21598

20527

The graphic is displayed as follows:

As you can see, in the case of 1,2,4 core support, Golang's indicators are ahead of node. JS, and the lead is not small, at around 30%. But at the time of the 8,16 nucleus, Golang showed no performance increase or slight decline, and node. JS was still increasing and eventually going ahead. This situation is very strange, supposedly, the server dual CPU, each 4 core, plus 8 physical cores, if said from 8 cores to 16 cores just CPU Hyper-threading simulation out, not the real physical core, then from 4 to 8 cores, is the real physical core of the increase, Arguably, performance should continue to grow. Using the top command to observe the usage of 16 logical CPUs, it was found that at the time of the 8 core and 16 cores, 16 logical CPUs always had a low load of 3 to 6 Golang, that is, Golang did not fully use all the CPUs or the load was unbalanced. By contrast, node. JS has 16 logical CPUs to use when setting up 16 processes. It seems that the Golang self-dispatching CPU core algorithm is still a problem, not a good load, and node. JS Multi-process cluster scheme through the operating system to balance the load, the effect is better.

Although node. JS has all the logical CPUs used in 16 processes, but consumes basically between 25% and 45%, while Golang is setting 16 core support, the logical CPU load is only 20%! The average is only about 15%.

Looking back at the previous said node. JS does not use the latest version to compare the issue, I downloaded the latest version of 0.10.13, it is strange, compared to

0.8.15, the number of finishes per second has dropped by 20%-30%, which is not known to other people who have encountered this problem.

In addition, a simple test of Tornado3, Python version 2.6.5, because Python has no real multi-core or multi-threaded support, not to mention the 2.X version, so only a thread test, the data is 2,200 times/per second, performance only the first two 20%-30% . The gap is large,

And when the concurrency number increases to 2000, a socket error occurs: Apr_socket_recv:connection reset by Peer (104)

node. js and Golang are stable under set 5,000 concurrency.

Of course, the above test does not involve the optimization of operating system parameters, the test code is very simple HelloWorld, the actual development process, there are too many factors affecting the performance of the system, the application code needs to call different class libraries, The quality of the class library implementation and the frequency of use may have a significant impact on performance, such as assuming that our application requires a large amount of disk I/O, when the I/O library for efficient read and write to the performance of the application has a significant impact, or the coding process of poor algorithm or logic may lead to significant performance loss, Will completely counteract the improvement of the language itself in performance optimization, such as the rational use of the cache from the program design, can make some operational performance of the application of an order of magnitude and so on.