quic-goとTCPのベンチマーク

私は今、quic-mqというQUICを使用したメッセージブローカーを作っています。

先日、quic-mqとRedisのPubSubのベンチマークを書いてみました。

一度に送信するデータが小さいときはquic-mqの方が速かったのですが、データが大きいときは大幅に遅くなるという結果になりました。

quic-mqの方はメモリアロケーションが多かったので恐らく無駄に割当が発生するようなコードを書いていたのだろうと思いコードを見直してみたのですが、そのような部分は見つかりませんでした。

quic-goを使用しているのが遅い原因ではないかと疑い、TCPとquic-goでechoサーバのベンチマークを書いてみました。

quic-goはIETF QUICのGo実装です。

BenchmarkQUIC-8             6103            181264 ns/op            6096 B/op         86 allocs/op
BenchmarkTCP-8             99586             12198 ns/op               0 B/op          0 allocs/op

quic-goの方が10倍以上遅いという結果になりました。

TCPでは0 allocs / opなのに対し、quic-goでは6096 B / opとなりました。

quic-goでは送受信の度に割当が発生しているのではないかと考えています。

QUICの仕様が原因なのかquic-goの実装が原因なのかはわからないのでQUICのドラフトとquic-goの実装を読んでみます。