Fasthttp 為什么比標(biāo)準(zhǔn)庫快 10 倍 ?

作者：蠻荊 2023-04-07 08:17:39

本文不會(huì)講解 fasthttp 的應(yīng)用方法，而是會(huì)重點(diǎn)分析 fasthttp 高性能的背后實(shí)現(xiàn)原理。

概述

fasthttp? 是一個(gè)使用 Go 語言開發(fā)的 HTTP 包，主打高性能，針對(duì) HTTP 請(qǐng)求響應(yīng)流程中的 hot path? 代碼進(jìn)行了優(yōu)化，達(dá)到零內(nèi)存分配，性能比標(biāo)準(zhǔn)庫的 net/http 快 10 倍。

上面是來自官方 Github 主頁的項(xiàng)目介紹，拋開其介紹內(nèi)容不談，光從名字本身來看，作者對(duì)項(xiàng)目代碼的自信程度可見一斑。

本文不會(huì)講解 fasthttp? 的應(yīng)用方法，而是會(huì)重點(diǎn)分析 fasthttp 高性能的背后實(shí)現(xiàn)原理。

基準(zhǔn)測(cè)試

我們可以通過基準(zhǔn)測(cè)試看看 fasthttp? 是否真的如描述所言，吊打標(biāo)準(zhǔn)庫的 net/http，下面是官方提供的基準(zhǔn)測(cè)試結(jié)果:

net/http

$ GOMAXPROCS=4 go test -bench='HTTPClient(Do|GetEndToEnd)' -benchmem -benchtime=10s
BenchmarkNetHTTPClientDoFastServer-4                      2000000       8774 ns/op     2619 B/op       35 allocs/op
BenchmarkNetHTTPClientGetEndToEnd1TCP-4                    500000      22951 ns/op     5047 B/op       56 allocs/op
BenchmarkNetHTTPClientGetEndToEnd10TCP-4                  1000000      19182 ns/op     5037 B/op       55 allocs/op
BenchmarkNetHTTPClientGetEndToEnd100TCP-4                 1000000      16535 ns/op     5031 B/op       55 allocs/op
BenchmarkNetHTTPClientGetEndToEnd1Inmemory-4              1000000      14495 ns/op     5038 B/op       56 allocs/op
BenchmarkNetHTTPClientGetEndToEnd10Inmemory-4             1000000      10237 ns/op     5034 B/op       56 allocs/op
BenchmarkNetHTTPClientGetEndToEnd100Inmemory-4            1000000      10125 ns/op     5045 B/op       56 allocs/op
BenchmarkNetHTTPClientGetEndToEnd1000Inmemory-4           1000000      11132 ns/op     5136 B/op       56 allocs/op

fasthttp

$ GOMAXPROCS=4 go test -bench='kClient(Do|GetEndToEnd)' -benchmem -benchtime=10s
BenchmarkClientDoFastServer-4                            50000000        397 ns/op        0 B/op        0 allocs/op
BenchmarkClientGetEndToEnd1TCP-4                          2000000       7388 ns/op        0 B/op        0 allocs/op
BenchmarkClientGetEndToEnd10TCP-4                         2000000       6689 ns/op        0 B/op        0 allocs/op
BenchmarkClientGetEndToEnd100TCP-4                        3000000       4927 ns/op        1 B/op        0 allocs/op
BenchmarkClientGetEndToEnd1Inmemory-4                    10000000       1604 ns/op        0 B/op        0 allocs/op
BenchmarkClientGetEndToEnd10Inmemory-4                   10000000       1458 ns/op        0 B/op        0 allocs/op
BenchmarkClientGetEndToEnd100Inmemory-4                  10000000       1329 ns/op        0 B/op        0 allocs/op
BenchmarkClientGetEndToEnd1000Inmemory-4                 10000000       1316 ns/op        5 B/op        0 allocs/op

基準(zhǔn)結(jié)果對(duì)比

從基準(zhǔn)測(cè)試結(jié)果來看，fasthttp? 的執(zhí)行速度要比標(biāo)準(zhǔn)庫的 net/http? 快很多，此外，fasthttp? 的內(nèi)存分配方面優(yōu)化到了 0?, 完勝 net/http。

核心優(yōu)化點(diǎn)

筆者選擇的 valyala/fasthttp[1] 版本為 v1.45.0。

對(duì)象復(fù)用

workerPool

workerpool? 對(duì)象表示連接處理? 工作池，這樣可以控制連接建立后的處理方式，而不是像標(biāo)準(zhǔn)庫 net/http? 一樣，對(duì)每個(gè)請(qǐng)求連接都啟動(dòng)一個(gè) goroutine? 處理，內(nèi)部的 ready? 字段存儲(chǔ)空閑的 workerChan? 對(duì)象，workerChanPool? 字段表示管理 workerChan 的對(duì)象池。

// workerpool.go
type workerPool struct {
    ready []*workerChan

    workerChanPool sync.Pool
}

type workerChan struct {
    lastUseTime time.Time
    ch          chan net.Conn
}

請(qǐng)求/響應(yīng) 對(duì)象

請(qǐng)求對(duì)象 Request? 和響應(yīng)對(duì)象 Response 都是通過對(duì)象池進(jìn)行管理的，對(duì)應(yīng)的代碼如下:

// client.go

var (
    requestPool  sync.Pool
    responsePool sync.Pool
)

// 從對(duì)象池中獲取 Request 對(duì)象
func AcquireRequest() *Request {
    ...
}

// 歸還 Request 對(duì)象到對(duì)象池中
func ReleaseRequest(req *Request) {
    ...
}

// 從對(duì)象池中獲取 Response 對(duì)象
func AcquireResponse() *Response {
    ...
}

// 歸還 Response 對(duì)象到對(duì)象池中
func ReleaseResponse(resp *Response) {
    ...
}

Cookie 對(duì)象

Cookie 對(duì)象也是通過對(duì)象池進(jìn)行管理的，對(duì)應(yīng)的代碼如下:

// cookie.go

var cookiePool = &sync.Pool{
    New: func() interface{} {
        return &Cookie{}
    },
}

// 從對(duì)象池中獲取 Cookie 對(duì)象
func AcquireCookie() *Cookie {
    ...
}

// 歸還 Cookie 對(duì)象到對(duì)象池中
func ReleaseCookie(c *Cookie) {
    ...
}

其他對(duì)象復(fù)用

$ grep -inr --include \*.go "sync.Pool" $(go list -f {{.Dir}} github.com/valyala/fasthttp) | wc -l

# 輸出如下
38

通過輸出結(jié)果可以看到，fasthttp? 中一共有 38 個(gè)對(duì)象是通過對(duì)象池進(jìn)行管理的，可以說幾乎復(fù)用了所有對(duì)象，So Crazy!

[]byte 復(fù)用

fasthttp? 中復(fù)用的對(duì)象在使用完成后歸還到對(duì)象池之前，需要調(diào)用對(duì)應(yīng)的 Reset? 方法進(jìn)行重置，如果對(duì)象中包含 []byte? 類型的字段，那么會(huì)直接進(jìn)行復(fù)用，而不是初始化新的 []byte?, 例如 URI? 對(duì)象的 Reset 方法:

// 重置 URI 對(duì)象
// 從方法的內(nèi)部實(shí)現(xiàn)中可以看到，類型為 []byte 的所有字段都被復(fù)用了
func (u *URI) Reset() {
    u.pathOriginal = u.pathOriginal[:0]
    u.scheme = u.scheme[:0]
    u.path = u.path[:0]
    u.queryString = u.queryString[:0]
    u.hash = u.hash[:0]
    u.username = u.username[:0]
    u.password = u.password[:0]

    u.host = u.host[:0]
    ...
}

此外，涉及到單個(gè)字段的修改，如果字段是 []byte? 類型，還是會(huì)直接復(fù)用，例如 Cookie 對(duì)象的這幾個(gè)方法:

func (c *Cookie) SetValue(value string) {
    c.value = append(c.value[:0], value...)
}

func (c *Cookie) SetValueBytes(value []byte) {
    c.value = append(c.value[:0], value...)
}

func (c *Cookie) SetKey(key string) {
    c.key = append(c.key[:0], key...)
}

func (c *Cookie) SetKeyBytes(key []byte) {
    c.key = append(c.key[:0], key...)
}

上面幾個(gè)方法的內(nèi)部實(shí)現(xiàn)中，無一例外，都對(duì) []byte 類型的參數(shù)進(jìn)行了復(fù)用。

[]byte 和 string 轉(zhuǎn)換

fasthttp? 專門提供了 []byte? 和 string? 這兩種常見的數(shù)據(jù)類型相互轉(zhuǎn)換的方法，避免了內(nèi)存分配 + 復(fù)制，提升性能。

// s2b_new.go
func b2s(b []byte) string {
    return *(*string)(unsafe.Pointer(&b))
}

// b2s_new.go
func s2b(s string) (b []byte) {
    bh := (*reflect.SliceHeader)(unsafe.Pointer(&b))
    sh := (*reflect.StringHeader)(unsafe.Pointer(&s))
    bh.Data = sh.Data
    bh.Cap = sh.Len
    bh.Len = sh.Len
    return b
}

高性能的 bytebufferpool

fasthttp? 并沒有直接使用標(biāo)準(zhǔn)庫中的 bytes.Buffer? 對(duì)象，而是引用了作者的另外一個(gè)包 valyala/bytebufferpool[2], 這個(gè)包的核心優(yōu)化點(diǎn)是避免內(nèi)存拷貝 + 底層 byte 切片復(fù)用，感興趣的讀者可以看看官方給出的基準(zhǔn)測(cè)試結(jié)果[3]。

避免反射

fasthttp? 中的所有對(duì)象深拷貝? 內(nèi)部實(shí)現(xiàn)中都沒有使用反射?，而是手動(dòng)實(shí)現(xiàn)的，這樣可以完全規(guī)避反射? 帶來的影響，例如 Cookie 對(duì)象的拷貝實(shí)現(xiàn):

// cookie.go
// Cookie 對(duì)象拷貝實(shí)現(xiàn)
func (c *Cookie) CopyTo(src *Cookie) {
    c.Reset()
    c.key = append(c.key, src.key...)
    c.value = append(c.value, src.value...)
    c.expire = src.expire
    c.maxAge = src.maxAge
    c.domain = append(c.domain, src.domain...)
    c.path = append(c.path, src.path...)
    c.httpOnly = src.httpOnly
    c.secure = src.secure
    c.sameSite = src.sameSite
}

從上面的代碼中可以看到，拷貝? 的內(nèi)部實(shí)現(xiàn)就是手動(dòng)挨個(gè)復(fù)制字段，非常原始的解決方案。

另外，請(qǐng)求對(duì)象 Request? 和響應(yīng)對(duì)象 Response? 的拷貝實(shí)現(xiàn)和 Cookie 有異曲同工之處:

// client.go
func (req *Request) CopyTo(dst *Request) {
    ...
}

func (resp *Response) CopyTo(dst *Response) {
  ...
}

fasthttp 的問題

軟件工程沒有銀彈，高性能的背后必然是以某些條件作為代價(jià)的，fasthttp 的主要問題有：

? 降低了代碼可讀性 (如果不了解 fasthttp 的設(shè)計(jì)理念，貿(mào)然讀代碼很可能無法理解各種方法實(shí)現(xiàn))
? 增加了開發(fā)復(fù)雜性，代碼開發(fā)量要比使用標(biāo)準(zhǔn)庫高，對(duì)象復(fù)用導(dǎo)致了申請(qǐng)/歸還流程彷佛回到了 C/C++ 語言手動(dòng)管理內(nèi)存模式
? 增加了開發(fā)者心智負(fù)擔(dān)，如果已經(jīng)習(xí)慣了標(biāo)準(zhǔn)庫的開發(fā)模式，很容易寫出 Bug
? 如果業(yè)務(wù)中有異步? 處理場(chǎng)景，框架核心的對(duì)象復(fù)用機(jī)制可能導(dǎo)致各種問題，如對(duì)象提前歸還、對(duì)象指針 hang 起、還有更嚴(yán)重的對(duì)象字段被重置后繼續(xù)引用 (這類業(yè)務(wù)邏輯問題比較難排查)

多核系統(tǒng)的性能優(yōu)化技巧

? 使用 reuseport 監(jiān)聽 (SO_REUSEPORT 允許在多核服務(wù)器上線性擴(kuò)展服務(wù)器性能，詳細(xì)信息請(qǐng)參閱這個(gè)鏈接[4] )
? 使用 GOMAXPROCS=1 為每個(gè) CPU 核運(yùn)行一個(gè)單獨(dú)的服務(wù)器實(shí)例 (進(jìn)程和 CPU 綁定)
? 確保多隊(duì)列網(wǎng)卡的中斷均勻分布在 CPU 內(nèi)核之間，詳細(xì)信息請(qǐng)參閱 [這個(gè)鏈接](https://blog.cloudflare.com/how-to-achieve-low-latency/

fasthttp 最佳實(shí)踐

? 盡可能復(fù)用對(duì)象和 []byte buffers, 而不是重新分配
? 使用 []byte 特性技巧
? 使用 sync.Pool 對(duì)象池
? 在生產(chǎn)環(huán)境對(duì)程序進(jìn)行性能分析，go tool pprof --alloc_objects app mem.pprof 通常比 go tool pprof app cpu.pprof 更容易體現(xiàn)性能瓶頸
? 為 hot path 上的代碼編寫測(cè)試和基準(zhǔn)測(cè)試
? 避免 []byte 和 string 直接進(jìn)行類型轉(zhuǎn)換，因?yàn)檫@可能會(huì)導(dǎo)致內(nèi)存分配 + 復(fù)制，可以參考 fasthttp 包內(nèi)的 s2b 方法和 b2s 方法
? 定期對(duì)代碼進(jìn)行競(jìng)態(tài)檢測(cè)[5], 一般會(huì)直接集成到 CI 中
? 使用 quicktemplate 而非 html/template 模板

是否采用 fasthttp

fasthttp? 是為一些高性能邊緣場(chǎng)景設(shè)計(jì)的，如果你的業(yè)務(wù)需要支撐較高的 QPS? 并且保持一致的低延遲時(shí)間，那么采用 fasthttp? 是非常合理的，反之 fasthttp? 可能并不適合 (增加開發(fā)復(fù)雜度和開發(fā)者心智負(fù)擔(dān))。大多數(shù)情況下，標(biāo)準(zhǔn)庫 net/http? 是更好的選擇，因?yàn)樗?jiǎn)單易用并且兼容性很高。如果你的業(yè)務(wù)流量很少，那么兩者之間的所謂性能差異幾乎可以忽略。