Go HTTP 框架性能大幅下降原因分析
作者：鼎铭
链接：
https://my.oschina.net/u/2950272/blog/2247104
最近在开发一个web 框架，然后业务方使用过程中，跟我们说，压测qps 上不去，我就很纳闷，httprouter + net/http.httpserver , 性能不可能这么差啊，网上的压测结果都是10w qps 以上，几个middleware 至于将性能拖垮？后来一番排查，发现些有意思的东西。
首先，我就简单压测hello world, 每个请求进来，我日志都不打，然后，打开pprof ,显示的情况如下：
图片地址：
https://oscimg.oschina.net/oscnet/0f00853302e7abdcae53612be9bba09c95b.jpg
（点击阅读原文查看原图）
这里futex 怎么这么高？看着上面的一些操作，addtimer, deltimer 我想到以前的自己实现的定时器，这估计是超时引起的。然后检查版本，go1.9, 然后框架默认为每个conn 设置了4个timeout，readtimeout, writetimeout, idletimeout, headertimeout ，这直接导致了定时器在添加和删除回调的时候，锁的压力特别大。
下面我们分析下，正常的加超时操作，到底发生了些什么，下面是个最简单的例子，为了安全，每个连接设置超时。
其中，ListenAndServe() 在调用accept 每个连接后，会调用 server.serve(), 根据是否添加超时，调用conn.SetReadDeadline等函数，对应的是 net/http/server.go,如下：
之后，con.SetReadDeadline 会调用 internal/poll/fd_poll_runtime.go的 fd.setReadDeadline，最后调用runtime/netpoll.go 的poll_runtime_pollSetDeadline， 这个函数会链接成internal/poll.runtime_pollSetDeadline。这个函数比较关键：
这里主要工作就是检查过期定时器，然后添加定时器，设置回调函数为netpollReadDeadline 或者netpollWriteDeadline。 从中可以看出添加和删除定时器操作为addtimer(&pd.rt), deltimer(&pd.rt)。
后面就是核心了，为啥加超时后这么慢，看下addtimer 的实现，timer 是个四叉小顶堆，每次添加一个超时，最后都需要对一个全局的timers 进行加锁，当qps 很高，一个请求，多次加锁，这性能能很高吗？
解决锁冲突改怎么办？分段锁是很常见一个思路，在go1.10 后，timers 由一个，变成64个，定时器被打散到64个锁上去，自然锁冲突就降低了。看1.10的runtime/time.go 可以发现定义如下，每个p有单独的timer， 每个timer能被多个p使用：
下面是go1.10 后的timer 数据结构（此图来源于网络）：
图片地址：
https://oscimg.oschina.net/oscnet/32c086ef71a2737f571a4dbf1944831d495.jpg
（点击阅读原文查看原图）
总结，网上很多httpserver 框架压测 qps 很高，但是它们的demo并没有设置超时，数据真实值会差很多。线上如果需要设置超时，需要注意go 的版本，qps 很高的情况下，最好使用1.10以上。最终我们不做任何其他操作情况下，仅将go 版本提高到1.10，qps 提高接近2倍。
开源中国征稿开始啦！
开源中国 www.oschina.net 是目前备受关注、具有强大影响力的开源技术社区，拥有超过 200 万的开源技术精英。我们传播开源的理念，推广开源项目，为 IT 开发者提供一个发现、使用、并交流开源技术的平台。
现在我们开始对外征稿啦！如果你有优秀的技术文章想要分享，热点的行业资讯需要报道等等，欢迎联系开源中国进行投稿。投稿详情及联系方式请参见：我要投稿