Passenger のワーカー(アプリケーションインスタンス)とセッションについて、いまいち理解できていない。
ワーカーについては、リクエスト処理後も生き続けている Rails アプリケーションの実体だという事は分かる。生き続けているから、生成処理にかかるコストを省略できて上手い方法だという事も分かる。
グローバルキューを使わない場合、ワーカーがプライベートなキューを持ち、そこに処理待ちのリクエストを溜め込むという事も分かる。この、処理待ちのリクエストがセッションと呼ばれる事も知った。passenger-memory-stats で表示されるのはセッションであるという事も知った。passenger-status で表示されるのはワーカーであるという事も知った(ワーカーが抱えるセッション数も表示される)。
さて、セッションは具体的に何なんでしょう。passenger-memory-stats で表示される内容をみると、結構なメモリを消費している様です。pid も持ってますね。名前的にワーカーだと勘違いしていましたが、数的にセッションですね。
セッションのソースコードのコメントを読む限り、読み書き用に 2 つのチャネルを持っていて、それを通じてバックエンドのアプリケーションと通信するらしき事は分かります。
- HTTP リクエスト／レスポンスをバックエンドプロセスに転送するためにセッションが使われる
- セッションはひとつの HTTP リクエスト／レスポンス
- バックエンドプロセスは Rails か Rack のアプリケーションインスタンス
- HTTP リクエストヘッダやボディを送る読み込みチャンネルがある
- HTTP レスポンスを送る書き込みチャンネルがある
- セッションごとに pid が存在している
- セッションはプールからゲットしてる
- で、セッションてどんなプロセスなの？
セッションがどんなプロセスであるのか、バックエンドプロセスとの通信が具体的にどのように行われているのか、詳細部分については理解しきれていません。
元々、ある問題についての調査で追いかけてみたわけですが、途中で本質的な問題はこれではないと気づいたために途中で放棄してしまいました。
このまま探るべきか、気が向いたときに再調査すべきか。悩むところです。
ひとまず、折角なのでここまでをメモがてら残しておきます。
