[kansaipm] use & fork

[SUGITA Toshinori]

杉田＠デジタルパッドです。
Apache::Registryについて調べてみたので、それに関連して。

# From: SUGITA Toshinori <sugita at d-pad.co.jp>
# Subject: Re: [kansaipm] use & fork 
# Date: Sat, 04 Oct 2003 15:19:30 +0900 (JST)

> > 　杉田さんのやりたいことがもう一つ具体的に掴めてないので、的はずれかもし
> > れませんが…。mod_perlのApache::Registryがまさにコンパイル結果をキャッシュ
> > しておいてパフォーマンスをよくするというアプローチだと思います。
> 
> なるほど、そのモジュールは知りませんでした。
> 一度調べてみます。

mod_perl + Apache::Registry について調べてみて、いくつか思い違いを
していたことがわかりました。

mod_perlってsystemやexecが使えないと思っていたのですが、勘違いのようですね。
先ほどだしたメールのその部分は、無視してください。(^^;

で、更に発生した疑問なんですが、mod_perlはapache上のモジュールとして
動作するわけですが、プロセス的には、どのような構成になるのでしょうか?

たとえば、fastcgiを使用した場合は、以下のようになっています。

  apache(ルートプロセス)
    + fastcgi(ルートプロセス) <-正しくは何と呼ぶのか知りませんが。。。
       + fastcgiスクリプト各プロセス
       + fastcgiスクリプト各プロセス
       + fastcgiスクリプト各プロセス
         .
         .
         .
    + apache(サブプロセス)
    + apache(サブプロセス)
    + apache(サブプロセス)
       .
       .
       .

これを見れば、各apacheサブプロセスに回されたリクエストから、
fastcgiの各プロセスに接続されて、リクエストを処理したあと、
apacheサブプロセスがクライアントに対してレスポンスを返すという
図式が(私の勝手な想像ですが)考えられます。

で、apache+mod_perlの場合もプロセスの動作を見てみたところ
以下のような感じで動いているようにみえます。
（判断の基準はpsコマンドで実行しながら追い掛けただけなので
  実際は違うのかも知れません）

1. apache(ルートプロセス)
    + apache(サブプロセス) + mod_perl
    + apache(サブプロセス) + mod_perl
    + apache(サブプロセス) + mod_perl
       .
       .
       .

これだと、apacheプロセスごとにmod_perlが使用する
プロセスがあることになるので、コンパイルがプロセス数分
行われることになります。これは私の望む動作ではありません。
（結局、基本的なところでfastcgiと特に変わるところがありません。）

やはり、複数プロセスでコンパイル結果をshareする（せめてshareして
いるように見せかける）のは無理なのでしょうか。。。
evalの結果をshere出来ないことを諦めれば、threadsが一番
希望するものに近いものができそうですが、こちらでは逆に
スレッド自身に伴う問題（共有メモリ、スレッドセーフ云々）が
恐いので。。。

既に、八方塞がりなのでしょうか。。。
今夜眠れなくなりそうです。

／／／／／／／／／／／／／／／／／／／／／／／／／／／／／／／
 SUGITA Toshinori 杉田 敏典      Digital Pad Inc.    .・.         
   E-MAIL  : sugita at d-pad.co.jp                       ●・
   WebPage : http://www.d-pad.co.jp/
   メール・スクランブル http://www.d-pad.co.jp/mail/scramble/
   アンケートしよう！   http://www.d-pad.co.jp/enquete/make/
   有名人にメールしよう http://www.d-pad.co.jp/mail/fame/
   アクセス解析サービス http://www.d-pad.co.jp/inspect/