2011年08月24日

最速TCPサーバーの条件 〜逆襲の Erlang と Haskell の挑戦〜

はてなブックマークに登録

釣った反響に応えて echo サーバーを改良していて PyCon JP の発表資料作成が進みません。 自業自得です。 methane です。

逆襲の Erlang

Erlangとは何だったのか でのベンチマーク結果では Erlang のスコアが奮わなかったのですが、 github で 性能改善する pull request をいただきました。 性能が悪かった原因ですが、実は backlog がデフォルトだと 5 で、ベンチマーク開始時の 大量の接続要求を捌ききれていないという状況でした。

高負荷サイトのボトルネックを見つけるには で紹介されている事例と同じ現象ですが、こちらのほうが backlog が小さく、 しかもベンチマーク用クライアントはほぼ同時に大量に接続をしてくるという条件で よりシビアに現象が発生してしまいました。

この問題が修正された Erlang は、 Go を超えて一気にランキング上位に踊り出ました。

Haskell の挑戦

@kazu_yamamotoさんから、 Haskell 版も 同じ環境でベンチマークして欲しいという reply があり、弊社 takada-at が昔作成した echo サーバーを @kazu_yamamoto さんからのアドバイスを受けながら改良して、 GHC 7.0.3 で計測しました。

GHCはGoなどと同じく(コルーチンではない)ユーザーランドスレッドを使って動いているのですが、 Go も Erlang も PyPy + Tornado も抜かして一気に C++ 版の次まで踊り出ました。 (@kazu_yamamoto さんの環境では C++(epoll) 版よりも良いスコアが出ているらしいです。 また、Haskell版は1コアしかCPUを使えていないので、forkを併用すればもっとスコアを伸ばす 余地があります)

関数型言語というと、なんとなくIOが苦手そうなイメージがあったのですが、 このベンチマークはそのイメージを完全にぶち壊してくれました。 さらに、ビルドしたバイナリは VM や外部の特別なランタイムに依存しておらず、 Haskellをインストールしていないサーバーにコピーしてもそのまま動かすことができるのも 個人的に高得点です。

ベンチマーク結果

今回は、 Erlang を修正したのと Haskell を追加した以外に、クライアントの設定を変えて クライアント側の負荷を下げることでより高い負荷を計測できるようにしました。 さらに実験環境の限界性能を試すべく、 C++(epoll) 版を fork したサーバーを用意しました。

試験に使用したスクリプトと試験結果は github上に 公開していますので、そちらをご覧ください。

echo3
Google Docs Spreadsheet

最速の条件

前回はthread版とepoll版ではほとんど差が無かったのですが、クライアントの設定変更を行い より高い負荷をかけたときに thread 版の方が一歩リードしました。これは、 epoll 版がデュアルコア CPUのうち1コアしか使っていないためです。

しかし、CPU負荷をモニタリングしていると、thread版はほんの少し速いだけなのにCPUを200% 使いきっており、CPU負荷のうちでも sys が多い状況になっていました。これは、ネイティブスレッドの コンテキストスイッチの負荷だと思います。

なので、最速TCPサーバーの条件とは、基本的にネイティブスレッドではなく軽量なユーザーランド スレッドかイベント駆動方式で接続の多重化を行いつつ、なおかつ複数コアを利用するために コア数程度のネイティブスレッドかプロセスを利用するという物になると思います。

この条件を検証するべく作成した epoll + fork 版サーバーは、予想通り thread 版を大きく 突き放すスコアをたたき出し、しかもまだCPU使用率には余力が残っていました。CPUを使い切れて いないのは、多分実験機のNICの Broadcom BCM5754 が複数コアに割り込みを分散する機能を もっていないためで、NICを増やしたり割り込み分散機能のあるNICを使えばもっと 差が広がると思います。

追記: 本当は速い gevent

gevent の作者から 、 Tornado のコードをそのまま gevent に移植したら Tornado より速くなったよというmerge request があったので、 ベンチマーク結果を更新しました。

gevent は Python の socket をラップして、 recv や send するときに自動的に greenlet というコルーチンを切り替えるクラスを提供しているのですが、このクラスが Python で実装 されているために、通信のたびに Python の関数呼び出しが数回発生していました。

先日のベンチマーク結果では17k req/sec, gevent の開発版を使ったら 19k req/sec なのですが、これは1リクエストあたり 50マイクロ秒程度で処理しているということであり、 Pythonの関数呼び出し数回によるオーバーヘッドが顕著に現れてしまいます。

ラップ版ソケットを使わず直接 io loop を使った Tornado のようなイベント駆動にしたら、 Python上の関数呼び出しが減って、 60k req/sec を処理できるようになりました。これは Go よりも高いスコアです。

とはいえ、 greenlet を使わないと gevent の魅力は半減しますし、 Python のコードを数回実行しただけで大幅に req/sec が下がるということはアプリケーションを 乗せるとすぐにIO部分がボトルネックではなくなるので、 gevent の greenlet を 使った多重化も通常の Python アプリケーションでは十分高速といえます。 現実的にはパフォーマンスのために greenlet を避ける必要に迫られることは無いでしょう


@methane


klab_gijutsu2 at 21:13│Comments(0)TrackBack(0)

トラックバックURL

この記事にコメントする

名前:
URL:
  情報を記憶: 評価: 顔   
 
 
 
Blog内検索
このブログについて
DSASとは、KLab が構築し運用しているコンテンツサービス用のLinuxベースのインフラです。現在5ヶ所のデータセンタにて構築し、運用していますが、我々はDSASをより使いやすく、より安全に、そしてより省力で運用できることを目指して、日々改良に勤しんでいます。
このブログでは、そんな DSAS で使っている技術の紹介や、実験してみた結果の報告、トラブルに巻き込まれた時の経験談など、広く深く、色々な話題を織りまぜて紹介していきたいと思います。
最新コメント
最新トラックバック
Archives