HTTPプロトコルパーサのオーバーヘッドは18%以下という話

「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場に関するの具体的な話。

Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのかを書く際に自作したベンチマークツールがあるのですが、それを使ったベンチマーク結果をid:tokuhiromがhttp://d.hatena.ne.jp/tokuhirom/20091001/1254355956にまとめてくれている*1。それについて、ちょっと補足と実測値を。

まず、コメントにも書いたんだけど、サーバのスループットを測る際にはTCP接続を多重化する必要があるので、-a 100 -n 100 -f *2のようなオプションでベンチマークをとってください。あと、ローカルホスト上での測定か、ホスト間での測定か、によっても当然結果は変わる。

自分の環境 (linux 2.6.18-028stab056; Pentium 4 3.2GHz) に対してリモートホストからベンチマークを取ると、以下のような結果になる。

プロトコル	requests / sec.
echo	67,388
http	55,002

つまり、HTTPプロトコルパーサのオーバーヘッドの「上限」は18%*3。いうまでもなく、実際のサーバでは、いろいろ処理を行うわけで、オーバーヘッドは、より小さくなる。

また、tokuhirom は、

この httpd はかなり処理をはしょっている実装なので、ちゃんと処理をすれば、ぐっと遅くなる。

http://d.hatena.ne.jp/tokuhirom/20091001/1254355956

と書いているが、この httpd がパース処理について不足しているのはリクエストが複数パケットに跨がった場合のバッファリングのみ。バッファリング処理についてはバッファプールを使うことで、大きなオーバーヘッドなく実装できるので、まず無視していいと自分は考えている。また、echod / httpd どちらにも欠けている処理として、たとえばタイムアウトの処理を実装すれば、両者の速度差は縮まることになる。

なので、上の18%というのは、おおざっぱな感覚値として間違っていないと思ってる。

なお、このサーバ実装で使っている http パーサは http://coderepos.org/share/browser/lang/c/picohttpparser/。epoll のラッパーは http://coderepos.org/share/browser/lang/c/picoev/

*1:さらに Makefile.PL もつけてくれた。tokuhirom++

*2:並列度100,同時接続数100,リクエストを投げる接続をローリングしない

*3:この比較は、何も「パース」処理を行わないechoプロトコルとの比較。バイナリプロトコルは、やはりなんらかの「パース」処理を行うので、テキストvs.バイナリ間の差はこれより(やや)小さい