golang多核陷阱一例

同时发布在独立博客。

之前一直觉得，在Golang中，针对高并发的状况，采用多核处理必定效果最优，可是项目实践证实事实不是这样的。

在Sniper项目中(一个结合了ab和siege优势的http负载测试工具)，原来一直设置cup使用数为系统cpu总数：

runtime.GOMAXPROCS(runtime.NumCPU())

在与ab的性能比较中一直有较大差距，GET请求局域网的一个10k大小的文件：

如下是ab的性能，并发100，总请求100k，执行时间16.082秒

Concurrency Level: 100
Time taken for tests: 16.082 seconds
Complete requests: 100000
Failed requests: 0
Write errors: 0
Total transferred: 1035500000 bytes
HTML transferred: 1024000000 bytes
Requests per second: 6218.04 [#/sec] (mean)
Time per request: 16.082 [ms] (mean)
Time per request: 0.161 [ms] (mean, across all concurrent requests)
Transfer rate: 62878.74 [Kbytes/sec] received

接下来采用sniper测试，设置runtime.GOMAXPROCS(runtime.NumCPU())

Transactions: 100000 hits
Availability: 100.00 %
Elapsed time: 20.82 secs
TotalTransfer: 0.00 MB
HTMLTransfer: 0.00 MB
Transaction rate: 4802.45 trans/sec
Throughput: 0.00 MB/sec
Successful: 100000 hits
Failed: 0 hits
TransactionTime: 0.00021 secs(mean)
ConnectionTime: 0.00010 secs(mean)
RequestTime: 0.00000 secs(mean)
ResponseTime: 0.00011 secs(mean)

能够看到测试一样的服务器，使用所有的cpu，sniper耗时20.82秒。

最后我再设置runtime.GOMAXPROCS(1)

Transactions: 100000 hits
Availability: 100.00 %
Elapsed time: 16.71 secs
TotalTransfer: 0.00 MB
HTMLTransfer: 0.00 MB
Transaction rate: 5985.03 trans/sec
Throughput: 0.00 MB/sec
Successful: 100000 hits
Failed: 0 hits
TransactionTime: 0.00017 secs(mean)
ConnectionTime: 0.00003 secs(mean)
RequestTime: 0.00000 secs(mean)
ResponseTime: 0.00014 secs(mean)

能够看到，sniper的执行时间降到16.71秒，下降了20%。

没想到优化了这么久的性能最后居然经过这样的办法前进一大步！

出现这种状况缘由在哪里？

目前我也解释不清楚，可能跟CPU的上下文切换有关，详细的原理须要再研究。有知道原理缘由的请指教。

update:

一个可能的缘由：在这里看到

和全部其余并发框架里的协程同样，goroutine里所谓“无锁”的优势只在单线程下有效，若是$GOMAXPROCS > 1而且协程间须要通讯，Go运行库会负责加锁保护数据。sniper存在大量的协程间通讯，多是锁影响了性能。