Ennoumuの処理割り当てについて

[sibapy]

いつもお世話になっております。

Ennoumuで複数プロセスを起動している場合に、リクエストに対して割り当てられるプロセスの決定はどのように行なっているのですか？
単純にラウンドロビンで割り当てられるのでしょうか？
複数プロセス起動時、あるリクエストがたまたま重い処理を行なっている場合、軽いリクエストまで止まっているようなので、このような質問をさせていただきました。

[arton]

Queue待ちのいずれかのプロセスに割り当てられます。それがラウンドロビンなのか、最後にリクエストを出したプロセスなのか、といった実装詳細はマイクロソフトの実装の問題で、ドキュメントはされていないのでわかりません。
したがって、可能性としては同じプロセスの別スレッドが次のリクエストを受信することもあり得ると思います。
ところで、重いプロセスというのは、同じプロセス内の他のスレッドを停止させてしまうのですか？

[sibapy]

いつもながら、早い回答ありがとうございます。

http.sys 任せという感じでしょうか？
そもそもEnnouはマルチスレッドで動作していないという認識なんですが、認識合っていますか？
Ennouが起動するプロセス数＝同時に処理できるリクエスト数という認識です。

重いプロセスとは、例えば大きなファイルのダウンロードなどで、Responseがなかなか返り切らないプロセスのことを言っています。CPUがぶん回って、他のスレッドを止めてしまうということではありません。

例えば、４つプロセスを起動している状態で、一つのプロセスが大きなダウンロードを始めたとすると、他のすぐにレスポンスを返すようなRequestのResponseが返ってこなくなります（何度かは動くので、順番にプロセスを割り当てられて、最終的にダウンロードを実行しているプロセスにRequestが行っているのではないのかと推測した次第です）。
ダウンロードが終了すると、止まっていたResponseが一斉に返される感じになります。

[arton]

#http.sys 任せという感じでしょうか？
そうです。
#そもそもEnnouはマルチスレッドで動作していないという認識なんですが、認識合っていますか？
ここは間違いです。想定している利用方法は、8プロセス×100スレッドで同時800リクエストとかなので。
ただ、ここは実験的に変えることができるので、よろしければ以下のennoumu.rbと交換して試していただけませんか？
https://gist.github.com/4250656
（今書いたのでテストしていないので、もしかするといきなり死ぬかも知れません。変更点は、run_single_threadというメソッドを呼ぶようにした点と、ennou.rbのrun_threadメソッドの処理をThreadに与えずに直接処理している点です。）

これでうまく動くようならば、マルチプロセス＋マルチスレッドのennoumuと、マルチプロセス＋シングルスレッドのennoumuを構成で切り替えられるようにしてみます。

[sibapy]

回答ありがとうございます。

失礼しました。Ennouはマルチスレッドで動作していたのですね。
http://msdn.microsoft.com/ja-jp/windowsazure/hh533281.aspx を読みました。

今一度、能楽堂のマニュアルを読み返したところ、
「問題点（あるいは制限事項）
WebアプリケーションがGVLを解除せずに同期的に外部リソース（RDBなど）を呼び出すスレッドが存在するとそのプロセスは止まります。
このような外部リソースを利用するアプリケーションはプロセス数を増やして実行してください。 」
というのがありました。

私が動作確認するのに、リクエストのレスポンスが返ってこない状況を作るべく、テストコードとしてSleepを埋め込んでいました。
これがつまり、GVLされていたということになるんですよね？
DB（Tiny_TDS）の使用や、外部コマンド（System)呼び出しなどもGVLされてしまうという認識で正しいですか？

質問ばかりですいません。

用意していただいたシングルスレッド版で確認したところ、リクエストが止まることはなくなったようです。
これは、（シングルスレッドなので）GVLされているプロセスにリクエストが行かなくなったからと解釈しています。
やはり全体的にレスポンスが悪くなったような気がしますが（主観です）、GVLの問題を回避するには、マルチプロセス＋シングルスレッドは有効だと思うので、切り替えができると嬉しいです。

[arton]

RubyのsleepはGVLを解除する（なので、別スレッドが動く）ので、そのSleepというのが何か次第です。WindowsAPIを呼んでいるのなら、その通りです。tiny_tdsは以前見たときはRubyのソケットを使っていなかったのでブロックされると思います。Rubyのsystemはブロックしないはずです。

[sibapy]

お世話になっております。
しばらく時間が取れなくて放置していたのですが、単純なサンプルにて再度確認してみました。

rails アプリを新規に generate し、20秒待ってレスポンスを返すアクションと、即座にレスポンスを返すアクションの２つを作成し、両者を同時に実行した場合、やはり、20秒の方が終了するまでリクエストが処理されないようです。
20秒待つのには、Rubyのsleepを使用しました。

---

class WaitController < ApplicationController
def index
sleep 20
end
def sample

end
end

---

• - - [23/Jan/2013 15:51:18] "GET /wait/sample " 304 - 0.0156
• - - [23/Jan/2013 15:51:19] "GET /wait/sample " 304 - 0.0312
• - - [23/Jan/2013 15:51:22] "GET /wait/sample " 304 - 0.0312
• - - [23/Jan/2013 15:51:41] "GET /wait/index " 304 - 20.0304
• - - [23/Jan/2013 15:51:41] "GET /wait/sample " 304 - 17.6124

EnnouでもEnnoumuでも同様になります。
何か確認ポイントなどございますでしょうか？

よろしくお願いいたします。

[sibapy]

いつもお世話になっております。
シングルスレッド版Ennoumuがコミットされていますが、
これを使用したい場合、ennoust.rb を ennoutmu.rb へ置き換えて使用すればよいでしょうか？

よろしくお願いします。

[arton]

そうです。それで合っています。たとえば、rackup -s Ennoust などです。

[sibapy]

ありがとうございます。
使わせてもらいます。

ちなみに、ennoust.rb の 42行目の -s Ennoumu は -s Ennoust の typo ですよね？