絵まで描いてもらっちゃいました！
やっぱり図になると文章だけよりずっと理解しやすいですね〜♪
- これ日記なん？ - ap4r解説してもらっちゃった！
ということで、自分もお絵かきしてみました（笑）
ちょっとごちゃごちゃしてしまいましたが、サーバの構成例と処理の流れになります。
1.クライアントが処理Aをリクエスト （赤の玉）
2.Apache（or Lighttpd）でロードバランシング
3.mongrel+Rails（or fastCGI+Rails）で処理Aを実行
4.処理Aの中でメッセージをキューにPUT （青の玉）
5.処理Aのレスポンスがクライアントに返る
6.捌き屋スレッドがメッセージをGETし、処理Bをリクエスト （緑の玉）
7.Apache（or Lighttpd）でロードバランシング
8.mongrel+Rails（or fastCGI+Rails）で処理Bを実行
9.処理Bのレスポンスが捌き屋スレッドに返る
5と6の間が非同期となり、「1〜5」と「6〜9」の一連の処理はそれぞれ同期で処理されています。
ということで、「6〜9」の間は捌き屋スレッドがそのメッセージの処理に占有されていることになりますね。
ap4rでもRindaみたいなモデルでの設定って可能なのかしら。つまり投げる側が処理Bの負荷に応じて手加減(!)できるみたいな。･･･（省略）･･･最大同時呼び出し数と呼び出しのタイムアウトの組み合わせで実現できるのかな、なんて思ったり。
AP4Rの捌き屋スレッドは設定ファイルでその数と引っこ抜く対象のメッセージを指定できます。なので、スレッドを多く設定しおけば（リソースの許す限り）さくさく処理されますし、ひとつしか設定しなければ順番に処理していくことになります。Rindaと似てますね。
ただ、現状はまだスレッドの構成を「静的」に決めておくことしかできません。なので、あらかじめ処理の流量を想定して設定ファイルに記載しておく必要があります。近い将来的には、これをコマンド制御で「動的に」増減できるようにしようと思っています。これで状況に合わせてAP4Rの動作を制御できるようになります。
同時実行ユーザー数やタイムアウトを閾値にして、ある程度「賢く」動作させることは可能だと思います。複数のAP4Rプロセス間で協調した同時実行ユーザー数の制御や状況に応じたタイムアウトの解釈のさせ方など、ちょっと手ごわい問題もありますが... （＾＾；
今回は素敵なフィードバックをありがとうございました！
疑問点やリクエストがあったらどしどしお寄せください。
いろいろアイデアを分けてもらいながらAP4Rを成長させていきたいなと思っています♪
