|PSGIのasync周りについて議論しているときに、そもそもasyncで何を実現したいのか具体的なビジョンが共有されて無いと話が進みづらいよねみたいな問題があるので、いくつか書いてみたいと思います。巨大なファイルを転送する巨大なファイルの転送を並列して受け付けたりアップロードプログレスを出したりとかデータのエクスポートとかデータベースからダンプしたCSVファイルとか巨大なファイルを動的に生成しなければならないようなケース出力するデータを生成している間にタイムアウトしてしまう場合があるので、データを逐一送るようにするとか、そういうもの。long-pollCometやchatアプリケーションなどでデータの入力があるまでレスポンスを待機させる。1つのスレッド/プロセスが専属で1つのリクエストを処理するようなモデルだと、これらの「時間のかかるリクエスト」は同時に多数に受け付けることが出来ない(スレッド/プロセス数までしか受け付けない)。非同期サーバーの要件ってのは、これらの処理をする際に一つのスレッドで複数のリクエストを同時に処理できること。抽象的に書くとリソースが準備可能になるまでレスポンスを遅延させる準備可能になるまで待っている間に他のリクエストを処理するユーザーからの入力や、キューからのデータ受信や生成をしたタイミングでレスポンスを逐次出力するここら辺の処理は実際はアプリケーション側の責任で行うことになるが、PSGIのレイヤーの話だと、1つのリクエストを処理している最中に、別のリクエストが処理される、という前提で設計されている必要がある。サーバーサイドでCoroやAnyEventを使うのが一般的になると、こういうことがごく簡単に行えるようになる。データベースへの問い合わせに0.5秒かかるとして、0.5秒の間にDBを使わない他のリクエストを処理したりできることになります。WWW上のデータを取得して加工するようなサービスや、応答速度が保証されていないウェブサービスのAPIを叩くようなケースも、準備可能になるまで他のリクエストを処理できるようになる。非同期処理が必要ないケース1リクエストあたりの処理時間1秒あたりに来るリクエストの最大件数そのサーバーで並列して処理できるリクエストの数から計算できると思う。既存のマルチスレッド/マルチプロセスのサーバーで、常にリクエスト処理待ちの待機しているプロセスがある状態の場合は(+その並列数でCPUのパフォーマンスが劣化しない場合は)、パフォーマンスが劣化することは無いので非同期処理を使う必要が無いでしょう。実際のところ「1秒あたりに来るリクエストの最大件数」というのは予測できないので、(long-pollやstreamingをしない)普通のアプリケーションにおいても非同期処理の導入はメリットになる(と、考えている)。接続において、待機時間がどの程度の割合を占めるか、という点で決定されると思う。http://d.hatena.ne.jp/kazuhooku/20090909/1252462255そのあたり失念していた。クライアントと直接通信するWWWサーバー/ロードバランサ/ReverseProxyについて言えば、クライアントがのろまなケースがあるのでリクエスト処理時間が予測できない。常に非同期処理のメリットがあると思う。のろまなクライアントというのは例えばslowlorisのような攻撃ツールも含まれる。1リクエストがスレッド/プロセスを占有してしまうようなモデルは、こういった攻撃手段に対して脆弱であることがわかっていて、対処が難しいので、今後I/O多重化を行うのは一般的になっていくと思う。waitが占める割合が重要になると思う。フロントとアプリケーションサーバーの通信が、のろまなクライアントの影響を受けるようになっているなら、そのあたりも考慮する必要がある。|http://jp.techcrunch.com/archives/20090907wordpress-enables-rsscloud-in-post-feeds/新しいフォーマット仕様で新しくない。2001年から全く使われていなかったもの。使われるとは思えない。Feedburner.「Googleの」と書いてしまうあたりが、ハイハイそういうことにしたいのですね、という感じ。Google以外も関わっているし、仕様と実装は公開されてるし、オープンに議論されている。別実装のハブもある、Googleのプロダクトを使う必要は無い。http://code.google.com/p/pubsubhubbub/wiki/Hubs逆にrsscloudのハブの作り方が全然わからない。実装が無いと使われるわけ無いでしょ。RSSCloudは通知しかサポートしてないhttp://code.google.com/p/pubsubhubbub/wiki/PriorArt通知後に配信元のフィードへのアクセスが集中する。リアルタイム通知が実現すると10万人の読者が居たら1分以内に10万アクセスが集中する。aggregatorの数だが)その負荷に耐えられないからFeedburnerを使うんでしょ?PubSubHubbubは通知だけじゃなくて、フィードの差分をPOSTすることで、この問題を解決しようとしている。|http://d.hatena.ne.jp/kazuhooku/20090907/1252328024http://www.fastcgi.com/devkit/doc/fcgi-spec.htmlプロトコル上でメリットがありそうなところって、これぐらいかな。FCGI_REQUEST_COMPLETE}}両方対応してないとダメそうだけど。コメントありがとうございます。