記一次golang的gzip優化

thinkboy發表於2017-07-26

背景

近期使用Golang官方的"compress/gzip"包對資料壓縮返回給App，此場景特性：資料不固定、高併發。在實際過程中發現一個簡單邏輯的API服務，幾百QPS的情況下CPU卻很高達到幾個核負載。

問題追蹤

通過golang自帶工具pprof抓圖分析CPU,如下圖(由於有業務程式碼，所以部分資訊遮蓋了):

通過此圖可以看出，整個工程裡有兩個CPU消耗大頭：1)GC高 2)大部分CPU耗在Gzip上.看方法屬於New操作，再加上GC高，很容易往一個方向上去想，就是物件建立過多造成。

於是google搜了一些資料發現有人嘗試優化gzip,地址:https://github.com/klauspost/compress/tree/master/gzip，但經過測試雖然速度提升20~30%，但是並不相容原生Gzip，似乎並不是一個很通用的方案。

分析原始碼

1.首先看下demo裡原生的使用方式

demo地址：https://github.com/thinkboy/gzip-benchmark

func OldGzip(wr http.ResponseWriter, r *http.Request) {
    buf := new(bytes.Buffer)
    w := gzip.NewWriter(buf)

    leng, err := w.Write(originBuff)
    if err != nil || leng == 0 {
        return
    }
    err = w.Flush()
    if err != nil {
        return
    }
    err = w.Close()
    if err != nil {
        return
    }
    b := buf.Bytes()
    wr.Write(b)

    // 檢視是否相容go官方gzip
    /*gr, _ := gzip.NewReader(buf)
    defer gr.Close()
    rBuf, err := ioutil.ReadAll(gr)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(rBuf))*/
}

2.其次看下官方gzip的實現,如下圖：

跟蹤程式碼尋找幾處與Pprof圖相關的有New操作的地方，首先第一張圖每次都會New一個Writer，然後在第二張圖裡的Write的時候，每次又都會為新建立的Writer分配一個壓縮器。對於物件的反覆建立有一個通用的思路，使用物件池。

3.嘗試使用物件池

通過上圖我們發現gzip的Writer有個Reset()方法，該方法呼叫的init()裡的實現是如果已經存在壓縮器，就複用並且Reset()。也就是說其實官方已經提供了一種方式讓使用者不再反覆New Writer。然後我們可以這樣改造下實現程式碼：

func MyGzip(wr http.ResponseWriter, r *http.Request) {
    buf := spBuffer.Get().(*bytes.Buffer)
    w := spWriter.Get().(*gzip.Writer)
    w.Reset(buf)
    defer func() {
        // 歸還buff
        buf.Reset()
        spBuffer.Put(buf)
        // 歸還Writer
        spWriter.Put(w)
    }()

    leng, err := w.Write(originBuff)
    if err != nil || leng == 0 {
        return
    }
    err = w.Flush()
    if err != nil {
        return
    }
    err = w.Close()
    if err != nil {
        return
    }
    b := buf.Bytes()
    wr.Write(b)

    // 檢視是否相容go官方gzip
    /*gr, _ := gzip.NewReader(buf)
    defer gr.Close()
    rBuf, err := ioutil.ReadAll(gr)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(rBuf))*/
}

我們給壓縮過程中用到的Buffer以及Writer定義物件池spBuffer、spWriter，然後每次api請求都從物件池裡去取，然後Reset，從而繞過New操作。

這裡容易產生一個疑問：物件池其實本身就是一個“全域性大鎖”，高併發場景下這把全域性大鎖影響有多大？(其實有一種深度優化的方式就是拆鎖，比如依據某個ID進行取餘取不同的物件池。這裡就拿一把大鎖來實驗).

下面看一下此次改造後的壓測結果(QPS: 3000):

不使用物件池(CPU 使用28個核左右):