|
|
|
|
|
||
|
||
| 
PSGIのasync周りについて議論しているときに、そもそもasyncで何を実現したいのか具体的なビジョンが共有されて無いと話が進みづらいよねみたいな問題があるので、いくつか書いてみたいと思います。
1. 巨大なファイルを転送する
2. ストリーミング
3. long-poll
1つのスレッド/プロセスが専属で1つのリクエストを処理するようなモデルだと、これらの「時間のかかるリクエスト」は同時に多数に受け付けることが出来ない(スレッド/プロセス数までしか受け付けない)。で、非同期サーバーの要件ってのは、これらの処理をする際に一つのスレッドで複数のリクエストを同時に処理できること。
もう少し抽象的に書くと
ここら辺の処理は実際はアプリケーション側の責任で行うことになるが、PSGIのレイヤーの話だと、1つのリクエストを処理している最中に、別のリクエストが処理される、という前提で設計されている必要がある。
サーバーサイドでCoroやAnyEventを使うのが一般的になると、こういうことがごく簡単に行えるようになる。例えばデータベースへの問い合わせに0.5秒かかるとして、0.5秒の間にDBを使わない他のリクエストを処理したりできることになります。あるいはWWW上のデータを取得して加工するようなサービスや、応答速度が保証されていないウェブサービスのAPIを叩くようなケースも、準備可能になるまで他のリクエストを処理できるようになる。
から計算できると思う。
既存のマルチスレッド/マルチプロセスのサーバーで、常にリクエスト処理待ちの待機しているプロセスがある状態の場合は(+その並列数でCPUのパフォーマンスが劣化しない場合は)、パフォーマンスが劣化することは無いので非同期処理を使う必要が無いでしょう。実際のところ「1秒あたりに来るリクエストの最大件数」というのは予測できないので、(long-pollやstreamingをしない)普通のアプリケーションにおいても非同期処理の導入はメリットになる(と、考えている)。
私見では、非同期処理 (スレッド内での I/O 多重化) を行うべきか否か、は、クライアントとの TCP 接続において、待機時間がどの程度の割合を占めるか、という点で決定されると思う。
そのあたり失念していた。
のろまなクライアントというのは例えばslowlorisのような攻撃ツールも含まれる。1リクエストがスレッド/プロセスを占有してしまうようなモデルは、こういった攻撃手段に対して脆弱であることがわかっていて、対処が難しいので、今後I/O多重化を行うのは一般的になっていくと思う。アプリケーションサーバーに関して言うと、フロントに置いてあるロードバランサ/ReverseProxyとの接続は十分速いはず、なので、純粋にアプリケーション内でのI/O waitが占める割合が重要になると思う。フロントとアプリケーションサーバーの通信が、のろまなクライアントの影響を受けるようになっているなら、そのあたりも考慮する必要がある。(裏側のI/O多重化を行っていないアプリケーションサーバーが攻撃を受ける or 裏側もI/O多重化する必要がある)
|
http://jp.techcrunch.com/archives/20090907wordpress-enables-rsscloud-in-post-feeds/
新しいフォーマット仕様で
新しくない。2001年から全く使われていなかったもの。今更使われるとは思えない。
http://rsscloud.org/walkthrough.html
Re Google's PubSubHubBub, their goal appears to flow updates of blog posts in association with 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万アクセスが集中する。(実際はfeed aggregatorの数だが)
その負荷に耐えられないからFeedburnerを使うんでしょ？PubSubHubbubは通知だけじゃなくて、フィードの差分をPOSTすることで、この問題を解決しようとしている。
|
http://d.hatena.ne.jp/kazuhooku/20090907/1252328024
http://www.fastcgi.com/devkit/doc/fcgi-spec.html
プロトコル上でメリットがありそうなところって、これぐらいかな。
4. Two instances of example 1, multiplexed onto a single connection. The first request is more difficult than the second, so the application finishes the requests out of order:
{FCGI_BEGIN_REQUEST, 1, {FCGI_RESPONDER, FCGI_KEEP_CONN}}
{FCGI_PARAMS, 1, "\013\002SERVER_PORT80\013\016SERVER_ADDR199.170.183.42 ... "}
{FCGI_PARAMS, 1, ""}
{FCGI_BEGIN_REQUEST, 2, {FCGI_RESPONDER, FCGI_KEEP_CONN}}
{FCGI_PARAMS, 2, "\013\002SERVER_PORT80\013\016SERVER_ADDR199.170.183.42 ... "}
{FCGI_STDIN, 1, ""}
{FCGI_STDOUT, 1, "Content-type: text/html\r\n\r\n"}
{FCGI_PARAMS, 2, ""}
{FCGI_STDIN, 2, ""}
{FCGI_STDOUT, 2, "Content-type: text/html\r\n\r\n<html>\n<head> ... "}
{FCGI_STDOUT, 2, ""}
{FCGI_END_REQUEST, 2, {0, FCGI_REQUEST_COMPLETE}}
{FCGI_STDOUT, 1, "<html>\n<head> ... "}
{FCGI_STDOUT, 1, ""}
{FCGI_END_REQUEST, 1, {0, FCGI_REQUEST_COMPLETE}}
両方対応してないとダメそうだけど。
少なくとも mod_fastcgi と libfcgi は RequestId による多重化をサポートしていませんし、そういう使われない機能を実現するために HTTP を捨てる必要はなかったのではないか、というのが (もちろん後だしジャンケンですが) 私の考えです。