« A Clever way to scale-out a web application (YAPC::Asia 2009 Presentation) | Main | パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ (BPStudy#25発表資料) »

September 22, 2009

「サーバ書くなら epoll 使うべき」は、今でも正しいのか

 多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか? echoサーバを書いて、ベンチマークを取ってみることにしました。

 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。

  • epoll も per-thread モデルも、良くスケールする
  • epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速

 少なくとも、1コネクション1スレッド、という選択肢が現実的であることは確かのようです(特にポータビィリティでイベント駆動モデルよりも優れていることを考えると注1)。また、今日ではマルチプロセッサ対応は必須ですから、マルチスレッド(マルチプロセス)+イベント駆動の二階建てにするよりも、1コネクション1スレッドのモデルの方が、必然的に単純になります。

 一方で、ロックの競合が問題になる場合や、最後の一滴までサーバのリソースを搾り取りたい場合は、まだイベント駆動でがんばるべきなのかもしれません注2

注1: イベント駆動モデルでは、ファイルシステムへのアクセス等も非同期 /Oを使用して書く必要があります
注2: mycached は、このケース

参考: 軽量スレッドブームだと思うので、そこらへんの情報をまとめてみる, Thousands of Threads and Blocking I/O, Completely Fair Scheduler によるマルチプロセッシング

TrackBack

TrackBack URL for this entry:
http://bb.lekumo.jp/t/trackback/404050/21608905

Listed below are links to weblogs that reference 「サーバ書くなら epoll 使うべき」は、今でも正しいのか:

Comments

Post a comment