Passenger のワーカーとセッション

Passenger のワーカー(アプリケーションインスタンス)とセッションについて、いまいち理解できていない。

ワーカーについては、リクエスト処理後も生き続けている Rails アプリケーションの実体だという事は分かる。生き続けているから、生成処理にかかるコストを省略できて上手い方法だという事も分かる。

グローバルキューを使わない場合、ワーカーがプライベートなキューを持ち、そこに処理待ちのリクエストを溜め込むという事も分かる。この、処理待ちのリクエストがセッションと呼ばれる事も知った。passenger-memory-stats で表示されるのはセッションであるという事も知った。passenger-status で表示されるのはワーカーであるという事も知った(ワーカーが抱えるセッション数も表示される)。

さて、セッションは具体的に何なんでしょう。passenger-memory-stats で表示される内容をみると、結構なメモリを消費している様です。pid も持ってますね。名前的にワーカーだと勘違いしていましたが、数的にセッションですね。

セッションのソースコードのコメントを読む限り、読み書き用に 2 つのチャネルを持っていて、それを通じてバックエンドのアプリケーションと通信するらしき事は分かります。

  • HTTP リクエスト/レスポンスをバックエンドプロセスに転送するためにセッションが使われる
  • セッションはひとつの HTTP リクエスト/レスポンス
  • バックエンドプロセスは Rails か Rack のアプリケーションインスタンス
  • HTTP リクエストヘッダやボディを送る読み込みチャンネルがある
  • HTTP レスポンスを送る書き込みチャンネルがある
  • セッションごとに pid が存在している
  • セッションはプールからゲットしてる
  • で、セッションてどんなプロセスなの?

セッションがどんなプロセスであるのか、バックエンドプロセスとの通信が具体的にどのように行われているのか、詳細部分については理解しきれていません。

元々、ある問題についての調査で追いかけてみたわけですが、途中で本質的な問題はこれではないと気づいたために途中で放棄してしまいました。

このまま探るべきか、気が向いたときに再調査すべきか。悩むところです。

ひとまず、折角なのでここまでをメモがてら残しておきます。

プロフィール

このブログ記事について

このページは、koshigoeが2009年8月 2日 22:54に書いたブログ記事です。

ひとつ前のブログ記事は「screen のペーストバッファの内容をコピー時に自動で OSX のクリップボードに送る」です。

次のブログ記事は「iMac 買った。なんか Snow Leopard だった」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。