建站
咨詢
售后
建站咨詢
新聞中心
概述
fasthttp? 是一個使用 Go 語言開發(fā)的 HTTP 包，主打高性能，針對 HTTP 請求響應(yīng)流程中的 hot path? 代碼進行了優(yōu)化，達到零內(nèi)存分配，性能比標(biāo)準(zhǔn)庫的 net/http 快 10 倍。
創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供旌陽網(wǎng)站建設(shè)、旌陽做網(wǎng)站、旌陽網(wǎng)站設(shè)計、旌陽網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、旌陽企業(yè)網(wǎng)站模板建站服務(wù)，10余年旌陽做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。
上面是來自官方 Github 主頁的項目介紹，拋開其介紹內(nèi)容不談，光從名字本身來看，作者對項目代碼的自信程度可見一斑。
本文不會講解 fasthttp? 的應(yīng)用方法，而是會重點分析 fasthttp 高性能的背后實現(xiàn)原理。
基準(zhǔn)測試
我們可以通過基準(zhǔn)測試看看 fasthttp? 是否真的如描述所言，吊打標(biāo)準(zhǔn)庫的 net/http，下面是官方提供的基準(zhǔn)測試結(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é)果對比
從基準(zhǔn)測試結(jié)果來看，fasthttp? 的執(zhí)行速度要比標(biāo)準(zhǔn)庫的 net/http? 快很多，此外，fasthttp? 的內(nèi)存分配方面優(yōu)化到了 0?, 完勝 net/http。
核心優(yōu)化點
筆者選擇的 valyala/fasthttp[1] 版本為 v1.45.0。
對象復(fù)用
workerPool
workerpool? 對象表示 連接處理? 工作池，這樣可以控制連接建立后的處理方式，而不是像標(biāo)準(zhǔn)庫 net/http? 一樣，對每個請求連接都啟動一個 goroutine? 處理， 內(nèi)部的 ready? 字段存儲空閑的 workerChan? 對象，workerChanPool? 字段表示管理 workerChan 的對象池。
// workerpool.go
type workerPool struct {
ready []*workerChan
workerChanPool sync.Pool
}
type workerChan struct {
lastUseTime time.Time
ch chan net.Conn
}
請求/響應(yīng) 對象
請求對象 Request? 和響應(yīng)對象 Response 都是通過對象池進行管理的，對應(yīng)的代碼如下:
// client.go
var (
requestPool sync.Pool
responsePool sync.Pool
)
// 從對象池中獲取 Request 對象
func AcquireRequest() *Request {
...
}
// 歸還 Request 對象到對象池中
func ReleaseRequest(req *Request) {
...
}
// 從對象池中獲取 Response 對象
func AcquireResponse() *Response {
...
}
// 歸還 Response 對象到對象池中
func ReleaseResponse(resp *Response) {
...
}
Cookie 對象
Cookie 對象也是通過對象池進行管理的，對應(yīng)的代碼如下:
// cookie.go
var cookiePool = &sync.Pool{
New: func() interface{} {
return &Cookie{}
},
}
// 從對象池中獲取 Cookie 對象
func AcquireCookie() *Cookie {
...
}
// 歸還 Cookie 對象到對象池中
func ReleaseCookie(c *Cookie) {
...
}
其他對象復(fù)用
$ grep -inr --include \*.go "sync.Pool" $(go list -f {{.Dir}} github.com/valyala/fasthttp) | wc -l
# 輸出如下
38通過輸出結(jié)果可以看到，fasthttp? 中一共有 38 個對象是通過對象池進行管理的，可以說幾乎復(fù)用了所有對象，So Crazy!
[]byte 復(fù)用
fasthttp? 中復(fù)用的對象在使用完成后歸還到對象池之前，需要調(diào)用對應(yīng)的 Reset? 方法進行重置，如果對象中包含 []byte? 類型的字段， 那么會直接進行復(fù)用，而不是初始化新的 []byte?, 例如 URI? 對象的 Reset 方法:
// 重置 URI 對象
// 從方法的內(nèi)部實現(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]
...
}
此外，涉及到單個字段的修改，如果字段是 []byte? 類型，還是會直接復(fù)用，例如 Cookie 對象的這幾個方法:
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...)
}上面幾個方法的內(nèi)部實現(xiàn)中，無一例外，都對 []byte 類型的參數(shù)進行了復(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? 對象，而是引用了作者的另外一個包 valyala/bytebufferpool[2], 這個包的核心優(yōu)化點是 避免內(nèi)存拷貝 + 底層 byte 切片復(fù)用，感興趣的讀者可以看看官方給出的 基準(zhǔn)測試結(jié)果[3]。
避免反射
fasthttp? 中的所有 對象深拷貝? 內(nèi)部實現(xiàn)中都沒有使用 反射?，而是手動實現(xiàn)的，這樣可以完全規(guī)避 反射? 帶來的影響，例如 Cookie 對象的拷貝實現(xiàn):
// cookie.go
// Cookie 對象拷貝實現(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)部實現(xiàn)就是手動挨個復(fù)制字段，非常 原始 的解決方案。
另外，請求對象 Request? 和響應(yīng)對象 Response? 的拷貝實現(xiàn)和 Cookie 有異曲同工之處:
// client.go
func (req *Request) CopyTo(dst *Request) {
...
}
func (resp *Response) CopyTo(dst *Response) {
...
}
fasthttp 的問題
軟件工程沒有銀彈，高性能的背后必然是以某些條件作為代價的，fasthttp 的主要問題有：
- ? 降低了代碼可讀性 (如果不了解 fasthttp 的設(shè)計理念，貿(mào)然讀代碼很可能無法理解各種方法實現(xiàn))
- ? 增加了開發(fā)復(fù)雜性，代碼開發(fā)量要比使用標(biāo)準(zhǔn)庫高，對象復(fù)用導(dǎo)致了 申請/歸還 流程彷佛回到了 C/C++ 語言手動管理內(nèi)存模式
- ? 增加了開發(fā)者心智負(fù)擔(dān)，如果已經(jīng)習(xí)慣了標(biāo)準(zhǔn)庫的開發(fā)模式，很容易寫出 Bug
- ? 如果業(yè)務(wù)中有 異步? 處理場景，框架核心的 對象復(fù)用 機制可能導(dǎo)致各種問題，如對象提前歸還、對象指針 hang 起、還有更嚴(yán)重的對象字段被重置后繼續(xù)引用 (這類業(yè)務(wù)邏輯問題比較難排查)
多核系統(tǒng)的性能優(yōu)化技巧
- ? 使用 reuseport 監(jiān)聽 (SO_REUSEPORT 允許在多核服務(wù)器上線性擴展服務(wù)器性能，詳細(xì)信息請參閱 這個鏈接[4] )
- ? 使用 GOMAXPROCS=1 為每個 CPU 核運行一個單獨的服務(wù)器實例 (進程和 CPU 綁定)
- ? 確保多隊列網(wǎng)卡的中斷均勻分布在 CPU 內(nèi)核之間，詳細(xì)信息請參閱 [這個鏈接](https://blog.cloudflare.com/how-to-achieve-low-latency/
fasthttp 最佳實踐
- ? 盡可能復(fù)用對象和 []byte buffers, 而不是重新分配
- ? 使用 []byte 特性技巧
- ? 使用 sync.Pool 對象池
- ? 在生產(chǎn)環(huán)境對程序進行性能分析，go tool pprof --alloc_objects app mem.pprof 通常比 go tool pprof app cpu.pprof 更容易體現(xiàn)性能瓶頸
- ? 為 hot path 上的代碼編寫測試和基準(zhǔn)測試
- ? 避免 []byte 和 string 直接進行類型轉(zhuǎn)換，因為這可能會導(dǎo)致 內(nèi)存分配 + 復(fù)制，可以參考 fasthttp 包內(nèi)的 s2b 方法和 b2s 方法
- ? 定期對代碼進行 競態(tài)檢測[5], 一般會直接集成到 CI 中
- ? 使用 quicktemplate 而非 html/template 模板
是否采用 fasthttp
fasthttp? 是為一些高性能邊緣場景設(shè)計的，如果你的業(yè)務(wù)需要支撐較高的 QPS? 并且保持一致的低延遲時間，那么采用 fasthttp? 是非常合理的， 反之 fasthttp? 可能并不適合 (增加開發(fā)復(fù)雜度和開發(fā)者心智負(fù)擔(dān))。大多數(shù)情況下，標(biāo)準(zhǔn)庫 net/http? 是更好的選擇，因為它簡單易用并且兼容性很高。 如果你的業(yè)務(wù)流量很少，那么兩者之間的 所謂性能差異 幾乎可以忽略。
Reference
- ? Go 高性能代碼的 30 個 Tips
- ? valyala/fasthttp[6]
- ? fasthttp中運用哪些go優(yōu)化技巧？
- ? fasthttp 快在哪里[7]
- ? fasthttp剖析[8]
引用鏈接
[1]? valyala/fasthttp: ??https://github.com/valyala/fasthttp??
[2]? valyala/bytebufferpool: ??https://github.com/valyala/bytebufferpool??
[3]? 基準(zhǔn)測試結(jié)果: ??https://omgnull.github.io/go-benchmark/buffer/??
[4]? 這個鏈接: ??https://www.nginx.com/blog/socket-sharding-nginx-release-1-9-1/??
[5]? 競態(tài)檢測: ??https://go.dev/doc/articles/race_detector??
[6]? valyala/fasthttp: ??https://github.com/valyala/fasthttp??
[7]? fasthttp 快在哪里: ??https://xargin.com/why-fasthttp-is-fast-and-the-cost-of-it/??
[8]? fasthttp剖析: https://www.jianshu.com/p/a0e766f8dcb0
網(wǎng)頁標(biāo)題：Fasthttp為什么比標(biāo)準(zhǔn)庫快10倍?
URL地址：http://m.fisionsoft.com.cn/article/coejhdj.html
