金利0無利息キャッシング – キャッシングできます

 | 

2009-09-08

非同期アプリケーションサーバーの要件と必要性について

23:01 | 非同期アプリケーションサーバーの要件と必要性について - 金利0無利息キャッシング – キャッシングできます を含むブックマーク はてなブックマーク - 非同期アプリケーションサーバーの要件と必要性について - 金利0無利息キャッシング – キャッシングできます

PSGIのasync周りについて議論しているときに、そもそもasyncで何を実現したいのか具体的なビジョンが共有されて無いと話が進みづらいよねみたいな問題があるので、いくつか書いてみたいと思います。

非同期処理が必要なケース

1. 巨大なファイルを転送する

  • 巨大なファイルの転送を並列して受け付けたりアップロードプログレスを出したりとか
  • データのエクスポートとかデータベースからダンプしたCSVファイルとか巨大なファイルを動的に生成しなければならないようなケース
    • 出力するデータを生成している間にタイムアウトしてしまう場合があるので、データを逐一送るようにするとか、そういうもの。

2. ストリーミング

3. long-poll

1つのスレッド/プロセスが専属で1つのリクエストを処理するようなモデルだと、これらの「時間のかかるリクエスト」は同時に多数に受け付けることが出来ない(スレッド/プロセス数までしか受け付けない)。で、非同期サーバーの要件ってのは、これらの処理をする際に一つのスレッドで複数のリクエストを同時に処理できること。

もう少し抽象的に書くと

  • リソースが準備可能になるまでレスポンスを遅延させる
    • 準備可能になるまで待っている間に他のリクエストを処理する
  • ユーザーからの入力や、キューからのデータ受信や生成をしたタイミングでレスポンスを逐次出力する

ここら辺の処理は実際はアプリケーション側の責任で行うことになるが、PSGIレイヤーの話だと、1つのリクエストを処理している最中に、別のリクエストが処理される、という前提で設計されている必要がある。

サーバーサイドでCoroやAnyEventを使うのが一般的になると、こういうことがごく簡単に行えるようになる。例えばデータベースへの問い合わせに0.5秒かかるとして、0.5秒の間にDBを使わない他のリクエストを処理したりできることになります。あるいはWWW上のデータを取得して加工するようなサービスや、応答速度が保証されていないウェブサービスAPIを叩くようなケースも、準備可能になるまで他のリクエストを処理できるようになる。

非同期処理が必要ないケース

  • 1リクエストあたりの処理時間
  • 1秒あたりに来るリクエストの最大件数
  • そのサーバーで並列して処理できるリクエストの数

から計算できると思う。

既存のマルチスレッド/マルチプロセスサーバーで、常にリクエスト処理待ちの待機しているプロセスがある状態の場合は(+その並列数でCPUのパフォーマンスが劣化しない場合は)、パフォーマンスが劣化することは無いので非同期処理を使う必要が無いでしょう。実際のところ「1秒あたりに来るリクエストの最大件数」というのは予測できないので、(long-pollやstreamingをしない)普通のアプリケーションにおいても非同期処理の導入はメリットになる(と、考えている)。

追記

私見では、非同期処理 (スレッド内での I/O 多重化) を行うべきか否か、は、クライアントとの TCP 接続において、待機時間がどの程度の割合を占めるか、という点で決定されると思う。

http://d.hatena.ne.jp/kazuhooku/20090909/1252462255

そのあたり失念していた。

  • クライアントと直接通信するWWWサーバー/ロードバランサ/ReverseProxyについて言えば、クライアントがのろまなケースがあるのでリクエスト処理時間が予測できない。
    • なので、常に非同期処理のメリットがあると思う。

のろまなクライアントというのは例えばslowlorisのような攻撃ツールも含まれる。1リクエストがスレッド/プロセスを占有してしまうようなモデルは、こういった攻撃手段に対して脆弱であることがわかっていて、対処が難しいので、今後I/O多重化を行うのは一般的になっていくと思う。アプリケーションサーバーに関して言うと、フロントに置いてあるロードバランサ/ReverseProxyとの接続は十分速いはず、なので、純粋にアプリケーション内でのI/O waitが占める割合が重要になると思う。フロントとアプリケーションサーバーの通信が、のろまなクライアントの影響を受けるようになっているなら、そのあたりも考慮する必要がある。(裏側のI/O多重化を行っていないアプリケーションサーバーが攻撃を受ける or 裏側もI/O多重化する必要がある)

kazuhookukazuhooku2009/09/08 12:48コメントありがとうございます。

少なくとも mod_fastcgi と libfcgi は RequestId による多重化をサポートしていませんし、そういう使われない機能を実現するために HTTP を捨てる必要はなかったのではないか、というのが (もちろん後だしジャンケンですが) 私の考えです。

CoralieCoralie2011/11/01 18:51Way to use the internet to help people solve pbromles!

cnyqgvcnyqgv2011/11/02 00:03ozXlBG <a href="http://tztpxrejkkdl.com/">tztpxrejkkdl</a>

lardsbsilardsbsi2011/11/03 23:10pjhHCk , [url=http://xsfdqxfpvopo.com/]xsfdqxfpvopo[/url], [link=http://gnjjtkelckln.com/]gnjjtkelckln[/link], http://hmckgigzyxlu.com/

tsdnburdtsdnburd2011/11/07 21:23EzDYmZ , [url=http://ywqejjqjscnn.com/]ywqejjqjscnn[/url], [link=http://orphnnrqhtdf.com/]orphnnrqhtdf[/link], http://tiqxtowkovzq.com/

 |