優雅的讀取http請求或響應的資料-續
之前釋出 【Go】優雅的讀取http請求或響應的資料續 文章,網友 “wxe” 諮詢:“優化前後的請求耗時變化有多大”,之前只分析了記憶體分配,這篇文章用單元測試的方式分析優化前後的耗時情況, 本文原始碼 。
非常感謝 “wxe” 網友的提問,讓我在測試過程中發現一個 json
序列化的問題。
之前我們優化了兩個部分, json
與 ioutil.ReadAll
, 先對比 ioutil.ReadAll
, 這裡測試的程式碼分成兩個部分做對比,一部分單純對比 ioutil.ReadAll
和 io.Copy
+ sync.Pool
,另一部分增加 jsoniter.Unmarshal
來延遲 pool.Put(buffer)
的執行, 原始碼 。
package iouitl_readall import ( "bytes" "io" "io/ioutil" "sync" jsoniter "github.com/json-iterator/go" ) var pool = sync.Pool{ New: func() interface{} { return bytes.NewBuffer(make([]byte, 4096)) }, } func IoCopyAndJson(r io.Reader) error { buffer := pool.Get().(*bytes.Buffer) buffer.Reset() defer pool.Put(buffer) res := Do(r) _, err := io.Copy(buffer, res) if err != nil { return err } m := map[string]string{} err = jsoniter.Unmarshal(buffer.Bytes(), &m) return err } func IouitlReadAllAndJson(r io.Reader) error { res := Do(r) data, err := ioutil.ReadAll(res) if err != nil { return err } m := map[string]string{} err = jsoniter.Unmarshal(data, &m) return err } func IoCopy(r io.Reader) error { buffer := pool.Get().(*bytes.Buffer) buffer.Reset() defer pool.Put(buffer) res := Do(r) _, err := io.Copy(buffer, res) if err != nil { return err } return err } func IouitlReadAll(r io.Reader) error { res := Do(r) data, err := ioutil.ReadAll(res) if err != nil { return err } _ = data return err }
測試程式碼如下 原始碼 :
package iouitl_readall import ( "bytes" "testing" ) var data = bytes.Repeat([]byte("ABCD"), 1000) func BenchmarkIouitlReadAll(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { err := IouitlReadAll(bytes.NewReader(data)) if err != nil { b.Error(err.Error()) } } }) } func BenchmarkIoCopy(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { err := IoCopy(bytes.NewReader(data)) if err != nil { b.Error(err.Error()) } } }) } func BenchmarkIouitlReadAllAndJson(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { err := IouitlReadAllAndJson(bytes.NewReader(data)) if err != nil { b.Error(err.Error()) } } }) } func BenchmarkIoCopyAndJson(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { err := IoCopyAndJson(bytes.NewReader(data)) if err != nil { b.Error(err.Error()) } } }) }
測試結果如下:
goos: darwin goarch: amd64 pkg: github.com/thinkeridea/example/iouitl_readall BenchmarkIouitlReadAll-85000002752 ns/op14496 B/op6 allocs/op BenchmarkIoCopy-82000000065.2 ns/op48 B/op1 allocs/op BenchmarkIouitlReadAllAndJson-810000020022 ns/op46542 B/op616 allocs/op BenchmarkIoCopyAndJson-810000017615 ns/op32102 B/op611 allocs/op
結論:
可以發現 IoCopy
方法是 IouitlReadAll
方法效率的 40 倍,記憶體分配也很少,而 IoCopyAndJson
和 IouitlReadAllAndJson
的效率差異極小僅有 2407ns
,大約是 1.13倍,不過記憶體分配還是少了很多的,為什麼會這樣呢,這就是 sync.Pool
的導致的, sync.Pool
每次獲取使用時間越短,命中率就越高,就可以減少建立新的快取,這樣效率就會大大提高,而 jsoniter.Unmarshal
很耗時,就導致 sync.Pool
的命中率降低了,所以效能下降極其明顯.
使用 io.Copy
+ sync.Pool
表面上執行效率不會有很大提升,但是會大幅度減少記憶體分配,從而可以減少 GC
的負擔,在單元測試中我們並沒有考慮 GC
的問題,而 GC
能帶來的效能提升會更有優勢。
在看一下 json
使用 sync.Pool
的效果吧 原始碼
package iouitl_readall import ( "bytes" "encoding/json" jsoniter "github.com/json-iterator/go" ) func Json(r map[string]string) error { data, err := json.Marshal(r) if err != nil { return err } _ = data return nil } func JsonPool(r map[string]string) error { buffer := pool.Get().(*bytes.Buffer) buffer.Reset() defer pool.Put(buffer) e := json.NewEncoder(buffer) err := e.Encode(r) if err != nil { return err } return nil } func JsonIter(r map[string]string) error { data, err := jsoniter.Marshal(r) if err != nil { return err } _ = data return nil } func JsonIterPool(r map[string]string) error { buffer := pool.Get().(*bytes.Buffer) buffer.Reset() defer pool.Put(buffer) e := jsoniter.NewEncoder(buffer) err := e.Encode(r) if err != nil { return err } return nil }
效能測試程式碼 原始碼 :
package iouitl_readall import ( "strconv" "strings" "testing" ) var request map[string]string func init() { request = make(map[string]string, 100) for i := 0; i < 100; i++ { request["X"+strconv.Itoa(i)] = strings.Repeat("A", i/2) } } func BenchmarkJson(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { err := Json(request) if err != nil { b.Error(err.Error()) } } }) } func BenchmarkJsonIter(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { err := JsonIter(request) if err != nil { b.Error(err.Error()) } } }) } func BenchmarkJsonPool(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { err := JsonPool(request) if err != nil { b.Error(err.Error()) } } }) } func BenchmarkJsonIterPool(b *testing.B) { b.RunParallel(func(pb *testing.PB) { for pb.Next() { err := JsonIterPool(request) if err != nil { b.Error(err.Error()) } } }) }
測試結果如下:
goos: darwin goarch: amd64 pkg: github.com/thinkeridea/example/iouitl_readall BenchmarkJson-810000013297 ns/op13669 B/op207 allocs/op BenchmarkJsonPool-810000013310 ns/op10218 B/op206 allocs/op BenchmarkJsonIter-85000002948 ns/op3594 B/op4 allocs/op BenchmarkJsonIterPool-82000006126 ns/op6040 B/op144 allocs/op PASS okgithub.com/thinkeridea/example/iouitl_readall12.716s
這裡使用了兩個 json
包, 一個是標準庫的,一個是 jsoniter
(也是社群反饋效率最高的),對比兩個包使用 sync.Pool
和不使用之間的差異,發現標準庫 json
包使用後記憶體有少量減少,但是執行效率稍微下降了,差異不是很大, jsoniter
包差異之所謂非常明顯,發現使用 sync.Pool
之後不僅記憶體分配更多了,執行效率也大幅度下降,差了將近3倍有餘。
是不是很奔潰,這是啥情況 jsoniter
本身就使用了 sync.Pool
作緩衝,我們使用 jsoniter.NewEncoder(buffer)
建立一個序列化例項,但是其內部並沒有直接使用 io.Writer
而是先使用緩衝序列化資料,之後寫入 io.Writer
, 具體程式碼如下:
// Flush writes any buffered data to the underlying io.Writer. func (stream *Stream) Flush() error { if stream.out == nil { return nil } if stream.Error != nil { return stream.Error } n, err := stream.out.Write(stream.buf) if err != nil { if stream.Error == nil { stream.Error = err } return err } stream.buf = stream.buf[n:] return nil }
這樣一來我們使用 buffer
做 json
序列化優化效果就大打折扣,甚至適得其反了。
再次感謝 “wxe” 網友的提問,這裡沒有使用實際的應用場景做效能測試,主要發現在效能測試中使用 http
服務會導致 connect: can't assign requested address
問題,所以測試用使用了函式模擬,如果有朋友有更好的測試方法歡迎一起交流。
謝謝你請我吃糖果
支付寶
微信