优化 golang net/http client 客户端存在的性能瓶颈

团队写了一个 api 网关服务，需要我进行并发和稳定性压测。一说压测大家会想起ab, wrk工具。 apache的ab性能有点差强人意，虽然事件用的也是epoll，奈何是单线程，不能泡满cpu。wrk是个好东西，基于redis ae_event封装的事件池，另外可以多线程模式和lua脚本。

但如果压测的逻辑比较复杂，那么lua就不好搞了，尤其需要第三方模块引入的时候。 作为两三年经验的gopher来说，自然会使用golang写压力测试脚本。

进行压测的时候，我们发现一个go性能问题，不管是http压测客户端还是api服务端，都存在cpu利用率不高的问题。不管你的协程加到多大，cpu总是跑不满，利用率不高。top看每个cpu核心的idle空闲不少，软中断也没有问题，内核日志也没有报错，网络的全连接和半连接也没有异常，网络带宽更不是问题。

注：5000个协程跟10000个协程，http压测场景下，他的cpu表现是一样的

分析问题的过程？

当我们把服务端的api转发功能关闭，只保留web功能。使用wrk压测可以看到服务端的cpu是可以被打满的。压测的客户端是http请求，api网关也是http请求，存在共性。那是不是可以猜测go net/http请求存在瓶颈？

下面是我们通过go tool pprof的分析报告。发现net/http transport的耗时有点大，transport只是个net/http的连接池，按道理应该很快。这里耗时相对大的有两个方法，tryPutIdleConn用来塞回连接，roundTrip用来获取连接。下面我们分析下net/http transport的源码。

先说下net/http transport连接池的数据结构，最直观的感受是锁多。

// xiaorui.cc

type Transport struct {
    idleMu   sync.Mutex
    wantIdle   bool // user has requested to close all idle conns
    idleConn   map[connectMethodKey][]*persistConn
    idleConnCh map[connectMethodKey]chan *persistConn
    reqMu      sync.Mutex
    reqCanceler map[*Request]func()
    altMu   sync.RWMutex
    altProto map[string]RoundTripper // nil or map of URI scheme => RoundTripper
    //Dial获取一个tcp 连接，也就是net.Conn结构，你就记住可以往里面写request, 然后从里面搞到response就行了
    Dial func(network, addr string) (net.Conn, error)
}

继续看下golang net/http是如何从连接池里获取可用连接的，入口是RoundTrip方法。

// xiaorui.cc

func (t *Transport) RoundTrip(req *Request) (resp *Response, err error) {
    ...
    pconn, err := t.getConn(req, cm)
    if err != nil {
        t.setReqCanceler(req, nil)
        req.closeBody()
        return nil, err
    }
    return pconn.roundTrip(treq)
}

Transport会先调用getConn获取连接，继而调用persistConn的roundTrip方法，各种channel的select。

// xiaorui.cc

func (t *Transport) getConn(req *Request, cm connectMethod) (*persistConn, error) {
    if pc := t.getIdleConn(cm); pc != nil {
        t.setReqCanceler(req, func() {})
        return pc, nil
    }
    type dialRes struct {
        pc  *persistConn
        err error
    }
    dialc := make(chan dialRes)
    prePendingDial := prePendingDial
    postPendingDial := postPendingDial
        ....
    cancelc := make(chan struct{})
    t.setReqCanceler(req, func() { close(cancelc) })
    // 启动了一个goroutine, 这个goroutine 获取里面调用dialConn搞到
    // persistConn, 然后发送到上面建立的channel  dialc里面， 
    go func() {
        pc, err := t.dialConn(cm)
        dialc <- dialRes{pc, err}
    }()
    idleConnCh := t.getIdleConnCh(cm)
    select {
    case v := <-dialc:
        // dialc 我们的 dial 方法先搞到通过 dialc通道发过来了
        return v.pc, v.err
    case pc := <-idleConnCh:
        // 这里代表其他的http请求用完了归还的persistConn通过idleConnCh channel发送来的
        handlePendingDial()
        return pc, nil
    case <-req.Cancel:
        handlePendingDial()
        return nil, errors.New("net/http: request canceled while waiting for connection")
    case <-cancelc:
        handlePendingDial()
        return nil, errors.New("net/http: request canceled while waiting for connection")
    }
}

最后分析下tryPutIdleConn返回连接的方法，当请求完毕后，根据各种条件来选择是塞回idle管道还是直接关闭。

// xiaorui.cc

func (t *Transport) tryPutIdleConn(pconn *persistConn) error {
    ...
    t.idleMu.Lock()
    defer t.idleMu.Unlock()
    waitingDialer := t.idleConnCh[key]
    select {
    case waitingDialer <- pconn:
        return nil
    default:
        if waitingDialer != nil {
            delete(t.idleConnCh, key)
        }
    }
    if t.wantIdle {
        return errWantIdle
    }
    if t.idleConn == nil {
        t.idleConn = make(map[connectMethodKey][]*persistConn)
    }
    idles := t.idleConn[key]
    if len(idles) >= t.maxIdleConnsPerHost() {
        return errTooManyIdleHost
    }
    for _, exist := range idles {
        if exist == pconn {
            log.Fatalf("dup idle pconn %p in freelist", pconn)
        }
    }
    t.idleConn[key] = append(idles, pconn)
    t.idleLRU.add(pconn)
    if t.MaxIdleConns != 0 && t.idleLRU.len() > t.MaxIdleConns {
        oldest := t.idleLRU.removeOldest()
        oldest.close(errTooManyIdle)
        t.removeIdleConnLocked(oldest)
    }
    if t.IdleConnTimeout > 0 {
        if pconn.idleTimer != nil {
            pconn.idleTimer.Reset(t.IdleConnTimeout)
        } else {
            pconn.idleTimer = time.AfterFunc(t.IdleConnTimeout, pconn.closeConnIfStillIdle)
        }
    }
    pconn.idleAt = time.Now()
    return nil
}

为什么cpu利用率上不去？

系统调用的统计里，我们发现futex和pselect6特别的多。futex是锁的系统调用，pselect6是高精度的休眠，他可以休眠微妙，纳秒。毫无疑问，不管你啥精度休眠都会线程的。

我们分析net/nttp transport源码发现其内部有各种的共享的channel和mutex，channel内部也有锁。我以前写过一篇文章阐述过golang锁竞争带来的问题，一方面syscall过多，另一方面出现cpu不饱和、利用率低的情况。

为啥cpu不饱和，你都sleep了还上哪去跑cpu，因没有触发handoffp，所以线程不会新增，已有的线程都在跑pselect6系统调用了，好了，直接贴runtime代码。

注： 朋友问了我一个问题，当runtime sleep的时候，为什么sysmon没有发生retake()，sysmon的代码里有说，当超过10ms的时候，才会发生抢占，继而handoffp，后startm ！ futexsleep的sleep也就几微秒，不会发出抢占调度，当在for循环里多次拿不到锁，他会yield切出去。

// xiaorui.cc

func lock(l *mutex) {
        ...

    // wait is either MUTEX_LOCKED or MUTEX_SLEEPING
    // depending on whether there is a thread sleeping
    // on this mutex. If we ever change l->key from
    // MUTEX_SLEEPING to some other value, we must be
    // careful to change it back to MUTEX_SLEEPING before
    // returning, to ensure that the sleeping thread gets
    // its wakeup call.
    wait := v

    for {
        // Try for lock, spinning.
        for i := 0; i < spin; i++ {
            for l.key == mutex_unlocked {
                if atomic.Cas(key32(&l.key), mutex_unlocked, wait) {
                    return
                }
            }
            procyield(active_spin_cnt)
        }
                ...
        futexsleep(key32(&l.key), mutex_sleeping, -1)
    }
}
// xiaorui.cc

func futexsleep(addr *uint32, val uint32, ns int64) {
    var ts timespec

    // Some Linux kernels have a bug where futex of
    // FUTEX_WAIT returns an internal error code
    // as an errno. Libpthread ignores the return value
    // here, and so can we: as it says a few lines up,
    // spurious wakeups are allowed.
    if ns < 0 {
        futex(unsafe.Pointer(addr), _FUTEX_WAIT_PRIVATE, val, nil, nil, 0)
        return
    }

    if sys.PtrSize == 8 {
        ts.set_sec(ns / 1000000000)
        ts.set_nsec(int32(ns % 1000000000))
    } else {
        ts.tv_nsec = 0
        ts.set_sec(int64(timediv(ns, 1000000000, (*int32)(unsafe.Pointer(&ts.tv_nsec)))))
    }
    futex(unsafe.Pointer(addr), _FUTEX_WAIT_PRIVATE, val, unsafe.Pointer(&ts), nil, 0)
}

解决go net/http cpu跑不满的方法?

问题的原因是锁竞争造成的，怎么减少net/http的锁竞争？多开几个net/http transport连接池不就行了。 然后针对连接池做轮询算法。这个轮询算法不要加锁 ！！！ 加锁又产生锁竞争了 ! 压测客户端和api网关改进调优的思路是一样的。

那么多开Transport连接池会有什么问题？ 连接数明显多了起来，另外前期预热期间会不断的new新连接，三次握手较多，请求会稍微慢一点，后面就ok了。另外http连接也会参与tcp的心跳检查，当然这类交互在内核层，上层无须关心。

// xiaorui.cc

var (

    clientList = []*http.Client{}
    ...
)

func makeClientList(count int) []*http.Client {
    clientList := make([]*http.Client, count, count)
    for index := 0; index < count; index++ {
        clientList[index] = newClient()
    }
    return clientList
}

func getClient() *http.Client {
    return clientList[rand.Int()%len(clientList)]
}

看下客户端在多开transport的cpu表现情况，cpu的利用率明显上来了。另外QPS吞吐也到了6W左右。

这时候我们再来看下go pprof cpu耗时图，发现 transport的耗时缩短了不少，不管是RoundTrip获取连接和tryPutIdleConn返回连接。

通过火焰图看到不少比net/http transport更加耗时的地方，比如readLoop和writeLoop耗时更大，分析这两个方法的源代码，各种的channel横飞，就现在来说没得优化，这两个方法是net/http最核心的读写逻辑，这个cpu消耗可以接受。还有一个io/ioutil.ReadAll的消耗，ReadAll内部不断的在makeSlice空间，也增加gc的消耗，后面可以加个sync.Pool缓冲池。

总结

这是我遇第三次遇到因为golang锁调度的问题，导致cpu利用率上不去，起先还天真以为是golang的协程调度的瓶颈。 去年在写cdn服务网关时，也遇到一个奇葩问题，cpu利用率也上不去，但是top的sys消耗比较大，通过strace抽样分析futex调用数高的吓人，最后跟分析原因是map的锁竞争引起的，改进成map分段锁解决。