Why is echo and gin so fast? How to create faster HTTP Router in GoConference 2023

1. EchoやGinはなぜ速いのか？
~Goで高速なHTTP routerを作るコツ~
1

2. 自己紹介
Nakamura Keisuke (@N9tE9:ネクテック)
Gopher 5年生
GoConference mini 2022 Autumn in Sendai LT登壇
静的解析/HTTP Router/gRPCコンパイラ(最近)
好きな標準パッケージ
sync net/http
DMM.com 22年度新卒入社
→ DMMプラットフォーム内におけるGoの認証SDKを開発
DMM.go の運営
2

3. Short Session の内容
- 本セッションで扱う HTTP Router について
- HTTP Router の実装のお話
- よく使われる sync.Pool
○ GoでHTTP Routerを実装するには？
○ 機能とパフォーマンスを落とさず提供する
- Router内部で高速に文字列処理を扱う方法
- EchoやGinで工夫されているところ
3

4. 本セッションで扱う HTTP Router について
1. 静的ルーティング (/health などURLのパスが変わらないもの)
2. パスパラメータルーティング (/:user のような動的に値が変わるもの)
4

5. 一般的な HTTP Router の内部実装
Trie Tree や Radix Tree といった木構造をベースに実装されている
/ h e a l t h
/ health
5

6. 一般的な HTTP Router の内部実装
Trie Tree や Radix Tree といった木構造をベースに実装されている
6
“/health”
/ h e a l t h
/ health

7. 一般的な HTTP Router の内部実装
Trie Tree や Radix Tree といった木構造をベースに実装されている
7
“/health”
/ h e a l t h
/ health

8. 一般的な HTTP Router の内部実装
Trie Tree や Radix Tree といった木構造をベースに実装されている
8
“/health”
/ h e a l t h
/ health
/health のハンドラ

9. HTTP Routerで使われている sync.Pool
sync.Poolの仕様 (https://pkg.go.dev/sync#Pool より)
1. スレッドセーフである
2. sync.Pool はGCによって削除される可能性がある
3. Poolが足りない場合は都度アロケートされる
9

10. HTTP Routerで使われている sync.Pool
sync.Poolの仕様 (https://pkg.go.dev/sync#Pool より)
1. スレッドセーフである
2. sync.Pool はGCによって削除される可能性がある
3. Poolが足りない場合は都度アロケートされる
→ HTTP Routerのユースケースとの相性がいいの？
10

11. GoでHTTP Routerを実装すると？
リクエスト → レスポンスを制御する箇所にルーティングのロジックを呼び出す
11

12. type Handler interface {
ServeHTTP(ReponseWriter, *Request)
}
リクエスト → レスポンスを制御する箇所にルーティングのロジックを呼び出す
→ http.Handler インターフェースを実装する
12
GoでHTTP Routerを実装すると？

13. リクエスト → レスポンスを制御する箇所にルーティングのロジックを呼び出す
→ http.Handler インターフェースを実装する
type Handler interface {
ServeHTTP(ReponseWriter, *Request)
}
→ ServeHTTPメソッドをRouterの構造体に実装すれば良い
13
GoでHTTP Routerを実装すると？

14. 14
リクエスト *Router.ServeHTTP()
/health
*Router.Search()
レスポンス
/health handler
handler 実行
GoでHTTP Routerを実装すると？

15. 15
リクエスト *Router.ServeHTTP()
/health
*Router.Search()
レスポンス
/health handler
handler 実行
*RouterをHTTP Serverとして動かしたい
→ ServeHTTPメソッドを実装したRouterの構造体をhttp.ListenAndServeなどに渡す
GoでHTTP Routerを実装すると？

16. (*http.Server).Serve() の挙動
16

17. (*http.Server).Serve() の挙動
for {
// 中略
if cc := srv.ConnContext; cc != nil {
connCtx = cc(connCtx, rw)
if connCtx == nil {
panic("ConnContext returned nil")
}
}
tempDelay = 0
c := srv.newConn(rw)
c.setState(c.rwc, StateNew, runHooks) // before Serve can return
go c.serve(connCtx)
}
参考: https://github.com/golang/go/blob/master/src/net/http/server.go
17

18. (*http.Server).Serve() の挙動
for {
// 中略
if cc := srv.ConnContext; cc != nil {
connCtx = cc(connCtx, rw)
if connCtx == nil {
panic("ConnContext returned nil")
}
}
tempDelay = 0
c := srv.newConn(rw)
c.setState(c.rwc, StateNew, runHooks) // before Serve can return
go c.serve(connCtx)
}
18
参考: https://github.com/golang/go/blob/master/src/net/http/server.go

19. (*http.Server).Serve() の挙動
for {
// 中略
if cc := srv.ConnContext; cc != nil {
connCtx = cc(connCtx, rw)
if connCtx == nil {
panic("ConnContext returned nil")
}
}
tempDelay = 0
c := srv.newConn(rw)
c.setState(c.rwc, StateNew, runHooks) // before Serve can return
go c.serve(connCtx)
}
1 リクエスト毎にgoroutineを起動してそう
19
参考: https://github.com/golang/go/blob/master/src/net/http/server.go

20. 1リクエストごとにgoroutineが起動するか確認する
どう確認する？
20

21. 1リクエストごとにgoroutineが起動するか確認する
どう確認する？
→ goroutineは内部でIDが振られている (goroutineID)
Handler内でgoroutineIDを出力すれば良い
21

22. Handler内でgoroutineIDを出力する
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
goroutineID := []byte(strings.Split(string(debug.Stack()), "¥n")[0])
w.WriteHeader(http.StatusOK)
// write goroutine id as response
w.Write(goroutineID)
})
srv := &http.Server{
Handler: mux,
}
srv.Addr = ":8001"
srv.ListenAndServe()
}
22

23. Handler内でgoroutineIDを出力する
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
goroutineID := []byte(strings.Split(string(debug.Stack()), "¥n")[0])
w.WriteHeader(http.StatusOK)
// write goroutine id as response
w.Write(goroutineID)
})
srv := &http.Server{
Handler: mux,
}
srv.Addr = ":8001"
srv.ListenAndServe()
}
23

24. debug.Stack()
goroutine 18 [running]:
runtime/debug.Stack()
/usr/local/Cellar/go/1.20.2/libexec/src/runtime/debug/stack.go:24 +0x65
…
created by net/http.(*Server).Serve
/usr/local/Cellar/go/1.20.2/libexec/src/net/http/server.go:3089 +0x5ed
24

25. debug.Stack()
goroutine 18 [running]:
runtime/debug.Stack()
/usr/local/Cellar/go/1.20.2/libexec/src/runtime/debug/stack.go:24 +0x65
…
created by net/http.(*Server).Serve
/usr/local/Cellar/go/1.20.2/libexec/src/net/http/server.go:3089 +0x5ed
25

26. リクエストを送って確認する
リクエストごとに異なる goroutine で処理されている
26

27. go のリクエスト → レスポンス
27
リクエスト待機
リクエスト待機

28. go のリクエスト → レスポンス
28
goroutine起動
リクエスト待機
リクエスト
goroutine起動
リクエスト待機

29. go のリクエスト → レスポンス
29
goroutine起動 リクエスト待機
リクエスト待機
リクエスト

30. go のリクエスト → レスポンス
30
ハンドラ処理 レスポンス
リクエスト
goroutine起動 リクエスト待機
リクエスト待機

31. go のリクエスト → レスポンス
31
ハンドラ処理 レスポンス
リクエスト
goroutine起動 リクエスト待機
リクエスト待機
ハンドラ処理 レスポンス
…

32. go のリクエスト → レスポンス
32
ハンドラ処理 レスポンス
リクエスト
goroutine起動 リクエスト待機
リクエスト待機
ハンドラ処理 レスポンス
…
Router側で提供したい共通の機能やデータは？

33. go のリクエスト → レスポンス
33
ハンドラ処理 レスポンス
リクエスト
goroutine起動 リクエスト待機
リクエスト待機
ハンドラ処理 レスポンス
…
理想
Router側で提供したい共通の機能やデータは？

34. go のリクエスト → レスポンス
34
ハンドラ処理 レスポンス
リクエスト
goroutine起動 リクエスト待機
リクエスト待機
ハンドラ処理 レスポンス
…
メモリプール
理想
Router側で提供したい共通の機能やデータは？

35. go のリクエスト → レスポンス
35
ハンドラ処理 レスポンス
リクエスト
goroutine起動 リクエスト待機
リクエスト待機
ハンドラ処理 レスポンス
…
メモリプール
スレッドセーフの必要がある
理想
Router側で提供したい共通の機能やデータは？

36. 複数ハンドラから共通の機能を参照したい時
goroutine毎に機能に必要なメモリをアロケートする必要がある
36

37. 複数ハンドラから共通の機能を参照したい時
goroutine毎に機能に必要なメモリをアロケートする必要がある
e.g.)
1. パスパラメータ値を保持するスライスやマップ
2. NotFound時の共通ハンドラ
3. カスタマイズした ResponseWriter (io.Writer)
…
37

38. 複数ハンドラから共通の機能を参照したい時
goroutine毎に機能に必要なメモリをアロケートする必要がある
e.g.)
1. パスパラメータ値を保持するスライスやマップ
2. NotFound時の共通ハンドラ
3. カスタマイズした ResponseWriter (io.Writer)
…
使いまわせるので Pool したい...
38

39. 複数ハンドラから共通の機能を参照したい時
goroutine毎に機能に必要なメモリをアロケートする必要がある
e.g.)
1. パスパラメータ値を保持するスライスやマップ
2. NotFound時の共通ハンドラ
3. カスタマイズした ResponseWriter (io.Writer)
…
使いまわせるので Pool したい...
→ sync.Poolを使う
39

40. sync.Pool を使う
sync.Poolの仕様 (https://pkg.go.dev/sync#Pool より)
1. スレッドセーフである
2. sync.Pool はGCによって削除される可能性がある
3. Poolが足りない場合は都度アロケートされる
40

41. sync.Pool を使う
sync.Poolの仕様 (https://pkg.go.dev/sync#Pool より)
1. スレッドセーフである
2. sync.Pool はGCによって削除される可能性がある
3. Poolが足りない場合は都度アロケートされる
HTTP Routerのユースケースとの相性がいいの？
→ HTTP Router のユースケースと相性が良い
41

42. sync.Pool を使う
sync.Poolの仕様 (https://pkg.go.dev/sync#Pool より)
1. スレッドセーフである
2. sync.Pool はGCによって削除される可能性がある
3. Poolが足りない場合は都度アロケートされる
HTTP Routerのユースケースとの相性がいいの？
→ HTTP Router のユースケースと相性が良い
42

43. sync.Pool を使う
sync.Poolの仕様 (https://pkg.go.dev/sync#Pool より)
1. スレッドセーフである
2. sync.Pool はGCによって削除される可能性がある
3. Poolが足りない場合は都度アロケートされる
HTTP Routerのユースケースとの相性がいいの？
→ HTTP Router のユースケースと相性が良い
43

44. sync.Pool を使った/使わない場合のパフォーマンス差
ベンチマーク対象コード: https://github.com/lkeix/myrouter/tree/add-sync-pool
poolする構造体
type Param struct {
key string
value string
}
type Context struct {
params []*Param
w http.ResponseWriter
r *http.Request
}
44

45. sync.Pool を使った/使わない場合のパフォーマンス差
ベンチマーク対象コード: https://github.com/lkeix/myrouter/tree/add-sync-pool
poolする構造体
type Param struct {
key string
value string
}
type Context struct {
params []*Param
w http.ResponseWriter
r *http.Request
}
45

46. sync.Poolを使った場合
sync.Poolを使わない場合
46

47. sync.Poolを使った場合
sync.Poolを使わない場合
47

48. sync.Poolを使った場合
sync.Poolを使わない場合
48

49. sync.Poolを使った場合
sync.Poolを使わない場合
49

50. sync.Poolのベンチマーク比較
構造体がそこまで大きくなくても、sync.Poolを使うことで...
1. アロケーションの回数は1/2に
2. メモリのアロケーションの容量(B/op)は1/5に
3. 速度は1.3倍程度速くなる
50

51. sync.Poolのベンチマーク比較
構造体がそこまで大きくなくても、sync.Poolを使うことで...
1. アロケーションの回数は1/2に
2. メモリのアロケーションの容量(B/op)は1/5に
3. 速度は1.3倍程度速くなる
51
高機能になると構造体が大きくなるので sync.Pool を使うことの恩恵が大きくなる
→ 高機能な HTTP Router を作る際にはsync.Poolが必要になる

52. HTTP Routing において高速に文字列を扱う
HTTP Routing における文字列マッチング
1. 木構造に登録されているノードとの文字列の部分一致
2. 登録されているパスパラメータの抽出
52

53. HTTP Routing において高速に文字列を扱う
HTTP Routing における文字列マッチング
1. 木構造に登録されているノードとの文字列の部分一致
2. 登録されているパスパラメータの抽出
→ 文字列の部分一致と結合
53

54. EchoやGinはどうやって実装している？
54
/ health
fuga

55. EchoやGinはどうやって実装している？
55
/ health
fuga
“/health”

56. EchoやGinはどうやって実装している？
56
/ health
fuga
“health” 一致箇所を空文字にする

57. EchoやGinはどうやって実装している？
57
/ health
“health”
fuga
どっちに進むべき？

58. EchoやGinはどうやって実装している？
58
/ health
“health”
fuga
頭文字のhをインデックスとして移動する

59. EchoやGinはどうやって実装している？
59
/ health
“health”
fuga
頭文字のhをインデックスとして移動する
※ 文字列一致の検証はノード移動後に行う

60. 移動すべきノードの検索について (N9tE9案)
60
/ health
“health”
fuga
この段階で文字列一致を検証した場合は？
ノード移動後の検証処理を省ける

61. 比較してみる
ベンチマークしたコード
https://github.com/lkeix/myrouter/blob/compare-string-process/compare/bench_test.go
- Trie Tree
- Echo/Gin Radix Tree (インデックスでの移動)
- N9tE9 Radix Tree (移動前に子ノードの文字列一致をする)
静的ルーティングにおける速度を比較する
61

62. 62
速度
1. Trie
2. Radix (インデックスでの移動)
3. N9tE9 Radix Tree (移動前に子ノードの文字列一致をする)

63. 63
速度
1. Trie
2. Radix (インデックスでの移動)
3. N9tE9 Radix Tree (移動前に子ノードの文字列一致をする)

64. パスパラメータルーティング
64

65. パスパラメータルーティング
65
/ health
:hogehoge
/ health
:hogehoge

66. パスパラメータルーティング
66
/ health
*http.Request.URL.Path = “/healthy”
:hogehoge
“/healthy”

67. パスパラメータルーティング
67
/ health
*http.Request.URL.Path = “/healthy”
:hogehoge
“y”

68. パスパラメータルーティング
68
/ health
*http.Request.URL.Path = “/healthy”
y が残り探索に失敗する
:hogehoge
“y”

69. パスパラメータルーティング
69
/ health
*http.Request.URL.Path = “/healthy”
:hogehoge
“healthy”

70. パスパラメータルーティング
70
/ health
*http.Request.URL.Path = “/healthy”
パスパラメータノードがあるノードまで戻る
→ バックトラック
Trieだとhealthの6ノード分戻る必要がある
:hogehoge
“healthy”

71. パスパラメータルーティング
71
/ health
*http.Request.URL.Path = “/healthy”
:hogehoge
“healthy”
パスパラメータノードがあるノードまで戻る
→ バックトラック
Trieだとhealthの6ノード分戻る必要がある

72. パスパラメータルーティング
72
/ health
:hogehoge
*http.Request.URL.Path = “/healthy”
healthy をパスパラメータとして抽出する

73. パスパラメータの抽出
73
次の ‘/’ または 空文字 までの文字列を抽出する
1. 一文字ずつ += で文字列結合する
2. bytes.Buffer.WriteString() を使って文字列結合する
3. スライスのインデックスで文字列を抽出する
4. 正規表現で抽出する

74. ベンチマーク
74
速度
1. インデックスから抽出
2. WriteStringでの結合
3. += で結合
4. 正規表現

75. HTTP Routing で高速に文字列を扱うには？
75
1. 次のノードの探索はインデックスを使って検索する
→ Echo や Gin では頭文字をインデックスとして扱っている
2. 文字列(パスパラメータ)の抽出はスライスを利用する
ただし、標準パッケージの最適化によって変わる可能性はある
1. データ構造の長所/短所を考慮しながら実装する
e.g.)
- Trie Treeはバックトラックに弱い
- Radix Treeは実装が複雑になる

76. Echo や Gin で工夫されているところ
76
1. sync.Poolで必要になる分は予めアロケートしておく
2. パスパラメータは独自のcontextで持つ
3. 関数呼び出しを減らす

77. Echo や Gin で工夫されているところ
77
sync.Poolで必要になる分は予めアロケートしておく

78. Echo や Gin で工夫されているところ
78
sync.Poolで必要になる分は予めアロケートしておく
Echo → パスパラメータのスライス、NotFound時のハンドラ、...
Gin → パスパラメータのスライス

79. Echo や Gin で工夫されているところ
79
sync.Poolで必要になる分は予めアロケートしておく
Echo → パスパラメータのスライス、NotFound時のハンドラ、...
Gin → パスパラメータのスライス
パスパラメータのスライスは共通して最大長アロケートしている
e.g.) “/:hoge/:fuga/:piyo” → 長さ3のスライスを用意する
→ スライスのappendは速度面からするとコストがかかる

80. Echo や Gin で工夫されているところ
80
パスパラメータは独自Contextで持つ

81. Echo や Gin で工夫されているところ
81
パスパラメータは独自Contextで持つ
リクエストのcontext.Contextに持たせることもできる
→ chi はこの実装でパスパラメータを格納している
context.Contextに格納する場合は速度面でかなり遅くなる

82. Echo や Gin で工夫されているところ
82
パスパラメータは独自Contextで持つ
リクエストのcontext.Contextに持たせることもできる
→ chi はこの実装でパスパラメータを格納している
context.Contextに格納する場合は速度面でかなり遅くなる
フレームワーク 設計思想 パフォーマンス
chi 標準net/httpパッケージに準拠 比較的遅い
Echo/Gin 内部はnet/httpをベースでパフォーマンスも求める まずまず
fasthttp 独自実装でパフォーマンスを求める 比較的速い

83. Echo や Gin で工夫されているところ
83
関数呼び出しを減らす

84. Echo や Gin で工夫されているところ
84
関数呼び出しを減らす
Echo → ルーティングの一部で goto 文が利用されている
Gin → ルーティングアルゴリズムは大きなトランザクションスクリプトで実装

85. Echo や Gin で工夫されているところ
85
関数呼び出しを減らす
Echo → ルーティングの一部で goto 文が利用されている
Gin → ルーティングアルゴリズムは大きなトランザクションスクリプトで実装
goto 文だとロジックを追いづらくならない?
→ goto 文が内部での関数呼び出しのようになっていて寧ろ読みやすい
個人的には Gin のトランザクションスクリプトの方が読みづらい

86. 高機能で高速なHTTP Routerを作るコツ (まとめ)
86
→ sync.Pool でハンドラ共通で利用する機能はPoolする
小さな構造体でもパフォーマンスが向上する
予め使う分は先にアロケートしておく
→ Routingの文字列操作は以下のようにする
1. 次の探索ノードはインデックスを使う
2. パスパラメータの抽出はスライスで抽出する
→ ルーティングにおいて、関数呼び出しは減らす
可読性 x パフォーマンス のトレードオフなので、実装者がここを見極める必要がある
→ どのようにAPIを提供したいかによってパフォーマンスも変わってくる

87. ご清聴ありがとうございました