[kansaipm] use & fork

SUGITA Toshinori sugita at d-pad.co.jp
Sat Oct 4 07:18:19 CDT 2003


杉田です。

# From: Dan Kogai <dankogai at dan.co.jp>
# Subject: Re: [kansaipm] use & fork 
# Date: Sat, 4 Oct 2003 20:34:10 +0900

> > で、更に発生した疑問なんですが、mod_perlはapache上のモジュールとして
> > 動作するわけですが、プロセス的には、どのような構成になるのでしょうか?
> 
> Apacheそのものと同一のprocessです。mod_perlとは、すなわちperlを内蔵したapacheなので。ですから、親process 
> でuseされたmoduleは、そのまま子processでも使えることになります。その意味で、fastcgiよりさらにefficientです。

なるほど、私は大きな勘違いをしていたわけですね。
これは、子プロセスでuseされたものに関しても同様でしょうか?

> > これだと、apacheプロセスごとにmod_perlが使用する
> > プロセスがあることになるので、コンパイルがプロセス数分
> > 行われることになります。これは私の望む動作ではありません。
> 
> というのは誤解で、基本的に子processは親processの環境を、useされたmoduleまで含めて全て継承するので、新たなcompile 
> は発生しません。

psコマンドの実行結果を見ていると、リクエストを受取ったプロセスの
使用メモリのみが増えていったように見えたのですが、これはなにか
私が更に勘違いしているのでしょうか。

apacheの*.confで初期ロードするモジュールを全く指定しないとして
cgiスクリプト自身やスクリプト中でuseしたモジュールはリクエストを受取った
プロセスがコンパイル/格納して、それ以外のapacheプロセスにはコンパイル結果は
伝播(という言い方が適当かどうかわかりませんが)していないように
思えるのですが。

ここに私の勘違いがあるのかな?

> > やはり、複数プロセスでコンパイル結果をshareする(せめてshareして
> > いるように見せかける)のは無理なのでしょうか。。。
> 
> というのは mod_perl  
> では当たり前にやっていることで、Apache::Registryは通常のCGIに対してもそれを可能にする仕組み 
> で、Apache::PerlRunはさらに広範囲のCGIに対して(効率を犠牲にして)それを可能にする仕組みだと考えればよいでしょう。

もしかして、常に親プロセスでコンパイルフェーズが実行されて、子プロセスで
実行フェーズが実行されていると言うことなのでしょうか?
それなら、コンパイル結果がすべてのプロセスで共有されるというのは
理解できます。

> > evalの結果をshere出来ないことを諦めれば、threadsが一番
> > 希望するものに近いものができそうですが、こちらでは逆に
> > スレッド自身に伴う問題(共有メモリ、スレッドセーフ云々)が
> > 恐いので。。。
> 
> Perlのthreadはまだそういう意味で実績が少なく、またmod_perlとの相性もあまりよくありません。あえてthreadを使うというので 
> あれば、Apache 2にmod_perl  
> 2を仕込んでやるというのがthreadを使う回答の中では最良だと思いますが、こう申し上げるのも何ですが、threadうんぬん言う前に、もう少し  
> *nix の process の仕組みを勉強した方がいいと思います。

threadsに関しては、私自身わからないことも多いし、いろいろな意味で
安定しているというわけでもないようなので出来ることなら使いたいとは思っていません。
processの仕組みを勉強したほうがいいのは、そのとおりのようですね。
まだかなりわかっていない部分があるみたいです。

> あと、「遅い」とか「効率が悪い」というのは、以外と思い込みの部分が大きなものです、きちんと Benchmark  
> した上で結論を出しましょう。そのための Tool もPerlにはたくさんあります。

これに関しては、fastcgiでのベンチマークはそれなりにはやってみました。
その結果、ファイルから読み込んで実行する内容を別とすると、
そのファイルの中身をparseする部分と、ファイル中のperlスクリプトを
コンパイルしている部分が処理としてもっとも重いようだという結論に達したため
今回このようなことを考えている次第です。

///////////////////////////////
 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/



More information about the Kansai-pm mailing list