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存在大量的协程间通信，可能是锁影响了性能。