标签：很多 极限 业务流程 defer 变化 客户 代码区 事件触发 多次
1.管道chan吞吐极限10,000,000，单次Put,Get耗时大约100ns/op，无论是采用单Go程，还是多Go程并发(并发数:100, 10000, 100000)，耗时均没有变化，Go内核这对chan进行优化。
解决之道：在系统设计时，避免使用管道chan传递主业务数据，避免将业务流程处理流程分割到对个Go程中执行，这样做减少chan传输耗时，和Go程调度耗时，性能会有很大的提升。
案例分析：nsq和nats都是实时消息队列，nsq在客户端端和服务端大量使用chan转发消息，导致性能不佳，只有100,000／s；而nats服务端在分发消息流程中，没有使用chan，只在客户端接收时使用chan，性能可达到1,000,000／s。
2.互斥锁Mutex在单Go程时Lock,Unlock耗时大约20ns/op，但是采用多Go程时，性能急剧下降，并发越大耗时越长，在Go1.5并发数达到1024耗时900ns/op，Go1.6优化到300ns/op，究其原因，是构建在CPU的原子操作之上，抢占过于频繁将导致，消耗大量CPU时钟，进而CPU多核无法并行。
解决之道：采用分区，将需要互斥保护的数据，分成多个固定分区(建议是2的整数倍，如256)，访问时先定位分区(不互斥)，这样就可降低多个Go程竞争1个数据分区的概率。
案例分析：Golang的Go程调度模块，在管理大量的Go程，使用的就是数据分区。
3.select异步操作在单管道时耗时120ns/op，但是随着管道数增加，性能线性下降，每增加1个管道增加100ns/op，究其原因，slelect时当chan数超过1后，Go内部是创建一个Go程，有它每1ms轮训的方式检查每个chan是否可用，而不是采用事件触发。
解决之道：在select中避免使用过多的管道chan分支，或者把无法用到的chan置为nil；解决select超时，避免使用单独的超时管道，应与数据返回管道共享。
案例分析：nsq和nats都是实时消息队列，由于nsq大量使用chan，这就必然导致大量使用select对多chan操作，结果是性能不高。
4.Go调度性能低下，当出现1,000,000Go程时，Go的调度器的性能急剧下降。
解决之道：避免动态创建Go程，服务端收到数据并处理的流程中，避免使用chan传递业务数据，这样会引起Go程调度。
案例分析：nsq和nats都是实时消息队列，由于nsq大量使用chan，这就必然导致在服务过程中，引起Go调度，结果是性能不高。
5.defer性能不高，每次defer耗时100ns，，在一个func内连续出现多次，性能消耗是100ns*n，累计出来浪费的cpu资源很大的。
解决之道：除了需要异常捕获时，必须使用defer；其它资源回收类defer，可以判断失败后，使用goto跳转到资源回收的代码区。
6.内存管理器性能低下，申请16字节的内存，单次消耗30ns，64字节单次消耗70ns，随着申请内存尺寸的增长，耗时会迅速增长。加上GC的性能在1.4, 1.5是都不高，直到1.6, 1.7才得到改善。
解决之道：建议使用pool，单次Put，Get的耗时大约在28ns，在并发情况下可达到18ns，比起每次创建，会节省很多的CPU时钟。
标签：很多 极限 业务流程 defer 变化 客户 代码区 事件触发 多次
原文地址：http://www.cnblogs.com/ipub520/p/7718905.html
