記一次golang的gzip最佳化

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

背景

近期使用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個核左右):

使用對象池(CPU 使用22個核左右):

通過CPU使用來看有消耗降低22%左右，由於QPS並不是很高，所以這裡對象池的“全域大鎖”的影響暫且可以忽略。

結論

針對官方Gzip的壓縮可以使用對象池來改善。

klauspost所提供的方案也列舉在demo中了，雖然屬於自己改了壓縮演算法不相容Golang官方包，但親測對壓縮速度也提升了很大百分比。使用該庫+對象池的方式可能會達到更顯著最佳化效果。

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

1976 次點擊