再次验证golang与node.js的http模块性能对比测试

之前看过性能对比测试的文章，是关于node.js和golang的http模块，简单的helloworld功能，原文在此：

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

再此文章之后，node.js和golang都升级了，node.js现在已经到了0.10,而golang也到了1.1版本，因此突然想在前人的基础上再做一次性能测试。

具体代码仍然沿用引用文章里面的。

硬件：双cpu，型号为xeon  E5620 2.40GHz，为4核cpu，因为支持超线程，所以系统显示逻辑cpu数为16个。

软件环境：centos6.0 。 node.js版本为0.8.15,没有使用现在最新的0.10.13 . golang为最新的1.1。两者从版本新旧上来看并不对等，不过最后我会把node.js版本升级来对比。

测试工具：apache ab，测试参数为并发1000，完成总数为200000次。

node.js在1.2.4,8,16进程下每秒完成请求数为：

5980

11300

15495

20435

21029

而golang在设置对应的核心数支持下的数据如下：

11109

16477

21874

21598

20527

图形显示如下：

从图中可以看到，在1,2,4核心支持的情况下，golang的指标都领先于node.js,而且领先幅度不小，在30%左右。但是到了8,16核的时候，golang就出现了性能没有提升或者小幅下降的现象，而node.js仍然为增势并最终反超。这种情况是很奇怪的，按理说，服务器双cpu，每颗4核心，加起来8个物理核心，如果说从8核心到16核只是cpu的超线程模拟出来的，不是真正的物理核心，那么从4核到8核，是真正的物理核心的增加，按理说性能应该继续增长的。通过top命令观察16个逻辑cpu的使用情况，发现golang在8核心和16核心的时候，16个逻辑cpu始终有3到6个负载很低，也就是golang没有完全使用所有的cpu或者是负载比较不均衡。相比之下node.js在设置16个进程的时候，16个逻辑cpu都使用到了。看来golang自行调度cpu核心的算法还是有问题，没有做到很好的负载，而node.js的多进程群集方案通过操作系统来平衡负载，效果更好。

不过node.js虽然在16个进程的时候所有的逻辑cpu都利用起来了，但是消耗基本在25%-45%之间，而golang在设置16个核心支持的时候，逻辑cpu负载最重也只有20%！平均只有15%左右。

回头回顾下前面说的node.js没用使用最新版本来对比的问题，我下载了最新的0.10.13版本，很奇怪的是，相比

0.8.15,每秒完成数反而出现了20%-30%的下降 ，这是什么情况，不知道其他人可碰到过这种问题。

另外，简单对tornado3 也做了测试，python的版本为2.6.5，因为python还没有真正的多核或者多线程支持，更不用说2.X版本，所以只做了一个线程的测试，数据为2200次/每秒 ，性能只有前两者的20%-30% .差距很大，

而且当并发数提升到2000的时候就出现了socket错误：apr_socket_recv: Connection reset by peer (104)

而node.js和golang在设置5000个并发下都很稳定。

当然，以上的测试并没有涉及到操作系统参数的优化，测试代码也只是非常简单的helloworld，实际开发过程中，有太多影响系统性能的因素，应用程序的代码需要调用不同的类库，类库实现的优良与否以及使用的频度可能会对性能有很大影响，比如假设我们的应用需要大量的磁盘i/o，这时候i/o库是否实现高效读写就对应用的性能有很大影响，抑或编码过程中劣质的算法或者逻辑可能会带来性能巨大损耗，则会完全抵消语言本身在性能优化上带来的提升，又比如从程序设计上合理使用缓存，可以让应用的某些操作性能提高一个数量级等等。。