mod_perlを使おう！
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん
01/11/07 17:42ID:+Gux2iOQ関連リンク等は>2
0553nobodyさん
2006/03/10(金) 11:42:37ID:???0554nobodyさん
2006/03/10(金) 11:46:02ID:???0556nobodyさん
2006/03/12(日) 21:33:04ID:???アパチと一心同体なのにな。
サービスによってはmod_xxx書いた方がいいし。
0558nobodyさん
2006/03/12(日) 23:27:09ID:???0559nobodyさん
2006/03/16(木) 19:48:08ID:???GATEWAY_INTERFACEにはCGI-Perlと値が入るようですが入りません。
ですが、MOD_PERLは定義されています。
confで指定したパスで今まで使ってたcgiがそのままでは動かなかったんで修正したら動きました。
こんなもんです？
0560nobodyさん
2006/03/17(金) 00:38:05ID:???> MP_COMPAT_1X
> MP_COMPAT_1X=1 or a lack of it enables several mod_perl 1.0 back-compatibility features, which are deprecated in mod_perl 2.0. It's enabled by default, but can be disabled with MP_COMPAT_1X=0 during the build process.
> When this option is disabled, the following things will happen:
> Environment variable GATEWAY_INTERFACE will be enabled only if PerlOptions +SetupEnv is enabled and its value would be the default:
> CGI/1.1
> and not:
> CGI-Perl/1.1
> The use of $ENV{GATEWAY_INTERFACE} is deprecated and the existance of $ENV{MOD_PERL} should be checked instead.
> MP_COMPAT_1X
> MP_COMPAT=1若しくはmod_perl1.0のバック互換性仕様の有効性が欠如するとmod_perl2.0には受け入れられません。デフォルトによって使用かのうですが構築中MP_COMPAT_1X=0によって使用不可となります。
> この条件が使用できないと次ぎのことが起こります。
> 環境変数GATEWAY_INTERFACEはPerlOptions +SetupEnvが使用可能でありその値がデフォルトのみにときに使用可能となります。
> CGI/1.1
> and not:
>
> CGI-Perl/1.1
> $ENV{GATEWAY_INTERFACE} は使用できません。そして代わりに $ENV{MOD_PERL} の存在がチェックされます。
0561nobodyさん
2006/03/25(土) 07:34:06ID:???ModPerl::Registryとの速度比較した人います？
0562nobodyさん
2006/03/25(土) 07:47:59ID:???0563nobodyさん
2006/03/30(木) 16:24:26ID:???サイトによってDBの接続先を変えたいと思ってます。
（両方とも同じスクリプトでDB接続先だけが違う）
この場合、うまいスクリプトのまとめかたはありますでしょうか？
理想としては、１つの外部ファイルにそれぞれのDB設定を
まとめて書いておいて、%ENV等の環境によって
使う変数を切替えるのがベストですが、mod_perl なので
外部ファイルは最初に全部キャッシュされてしまい、
どちらのDBにつながるのかがランダムになってしまいます。
0564nobodyさん
2006/03/30(木) 20:10:44ID:???レン鯖でランダムになる訳ないだろ。
0565nobodyさん
2006/03/31(金) 13:32:23ID:0vIICn80http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_
じゃだめ？
0567nobodyさん
NGNG0568nobodyさん
2006/04/05(水) 13:41:03ID:???0569nobodyさん
NGNG0570nobodyさん
NGNG0571nobodyさん
2006/04/05(水) 18:46:07ID:???負荷を計測みればいいのでは。
mod_perlはApacheの子プロセスにPerlのインタプリタを埋め込むので、メモリを
大きく消費します(ここのところははてなおやが詳しい。下は古い記事ですが)ので
安易に導入すると泣きを見るかもしれません
http://www.sixapart.jp/movabletype/developers/naoya/archives/2004/10/post.html
SpeedyCGIはサーバーの外でPerlインタプリタが常駐します
それで探しているものがベンチマークというわけで以下がひとつ(ただしりなざう)
http://tbox.jpn.org/wiki/linuzau/wiki.cgi?LinuxZaurus%B8%FE%A4%B1%A5%D3%A5%EB%A5%C9%2FApache%2BSpeedyCGI
0573nobodyさん
NGNG0574nobodyさん
2006/04/06(木) 18:36:05ID:???0575nobodyさん
2006/04/06(木) 19:51:29ID:???mod_perl は Perl スクリプトを高速実行「する為の」道具ではなく
Perl スクリプトを高速実行「させる事もできる」道具。
http://d.hatena.ne.jp/keyword/mod_perl
0576nobodyさん
NGNG最近は安定したんですかね。
0577nobodyさん
2006/04/06(木) 20:52:00ID:???ageんな
0578nobodyさん
2006/04/06(木) 22:57:19ID:???メモリが足んなくなったんじゃないか？
httpd.confさらしてみそ
"use strict;"がついていないと期待どおりの動作にならない
メモリがいくら積んでもスクリプトが悪いとメモリを大きく消費してしまう
(Apache1.3ではApache::PerlRun、Apache2ではModPerl::PerlRunであれば
スクリプトが悪くてもインタプリタが常駐するだけなので一応ある程度高速に
動作するがexit関数を使うとApacheごと落ちてしまう)
まさかmod_perlをApacheモジュール版のPHPと同じように捉えているのか
0580nobodyさん
2006/04/07(金) 00:50:07ID:45h+7cJz別にstrictプラグマが必須なわけじゃないし。
0581nobodyさん
2006/04/07(金) 01:45:40ID:???0582nobodyさん
2006/04/07(金) 05:42:19ID:???鯖の前まで逝って復旧処理が必要になる。
あのmixiでさえ、speedyじゃなくてmod_perl使ってるくらいだからなあ。
0583nobodyさん
2006/04/07(金) 06:47:18ID:???使ってるくらいだから何なんだ？
素直にわかりませんって言えばいいのに。
0584nobodyさん
2006/04/07(金) 08:27:12ID:???http://daemoninc.com/SpeedyCGI/ はリンク切れだし、
http://search.cpan.org/~horrocks/
http://sourceforge.net/projects/speedycgi/
を見ると、2.22 が 2003/10/11 に出たのが最後で、2年半も
更新されていないという点に多少不安を感じるけど、特に問題
はないの？
0585nobodyさん
2006/04/07(金) 08:56:03ID:???0586nobodyさん
2006/04/07(金) 08:56:47ID:???そうでもないよね。
0587nobodyさん
NGNG0589nobodyさん
2006/04/07(金) 11:40:32ID:???最近のは大丈夫なんじゃなかったっけ？
でもalarmとか使うとhttpdプロセスごと落ちたかも。
0590nobodyさん
2006/04/07(金) 11:42:39ID:???こけるときゃ一緒だぜ
0591nobodyさん
2006/04/07(金) 12:44:12ID:???0592nobodyさん
2006/04/07(金) 13:12:07ID:???Apacheモジュールを書くことが可能な点だと思う。
たとえば、掲示板スクリプトがあったとして、
アクセス規制をアクセス制御フェーズのモジュールにしてしまえば、
スクリプトからアクセス規制のコードをほとんど除けるとかね。
0593nobodyさん
2006/04/07(金) 13:23:06ID:???アプリ鯖でわざわざやることもなかろう。
0594nobodyさん
2006/04/07(金) 13:25:22ID:???0595nobodyさん
NGNGspeedyの存在を知らなかったのでmod_perlにしてしまっただけで、、
Apacheモジュールをperlで書けるようになるのは、
面白いかなぁと思うのですが、
サンプルスクリプトをあまり見ないので、
どうやって作るのかよくわからないのです。
0596nobodyさん
2006/04/07(金) 13:38:42ID:???> どうやって作るのかよくわからないのです。
Sledge とか Catalyst とか使ってればよくなくね？
0597nobodyさん
2006/04/07(金) 13:44:58ID:???http://perl.apache.org/
ここのドキュメンテーション１００回音読しろよ
0599nobodyさん
2006/04/07(金) 13:49:40ID:???0600nobodyさん
2006/04/07(金) 13:51:57ID:???0601nobodyさん
2006/04/07(金) 14:12:45ID:???0602nobodyさん
2006/04/07(金) 14:19:06ID:???0603nobodyさん
2006/04/07(金) 14:22:35ID:???俺は読めないけどフィーリングて凌いでるわ
0604nobodyさん
2006/04/07(金) 14:25:03ID:???以外の煽りに反応する馬鹿ww
0605nobodyさん
2006/04/07(金) 14:28:02ID:???0606nobodyさん
2006/04/07(金) 16:27:40ID:???0607nobodyさん
NGNG音読してもサンプルスクリプトが見つかりませんでした。
0608nobodyさん
2006/04/07(金) 17:44:36ID:???Apache拡張ガイド(上)
http://www.amazon.co.jp/exec/obidos/ASIN/4873110181/
↑の本のWebサポート(一部読めます)
http://www.modperl.com/
ぐらいかなぁ。
0609nobodyさん
2006/04/07(金) 18:00:28ID:???ttp://perl.apache.org/docs/2.0/user/index.html
ここの Part III: Coding は？
0610nobodyさん
2006/04/07(金) 19:10:52ID:???mod_perlだと落ちる原因わかったんですか？
0611nobodyさん
NGNG0612nobodyさん
NGNGメモリリークのテストで失敗してしまいました。
こういうのはどうしたらいいんでしょうか、、、
t/be_memleak..........ok 1/2 mem usage went from 2628K to 6256K in 1000 runs
t/be_memleak..........FAILED test 2
Failed 1/2 tests, 50.00% okay
0614nobodyさん
NGNGメモリリークが起きてるなら、
それを直したほうがいいかなぁ、、と。
0615nobodyさん
2006/04/09(日) 12:26:29ID:???検索したらこんなのありました。
ttp://rt.cpan.org/Public/Bug/Display.html?id=13521
去年の7月に最初に報告されてからずいぶん放置されてたようだけど、
4/2に着手になってるからいずれ直るかも?
0616nobodyさん
2006/04/09(日) 12:43:20ID:???0617nobodyさん
NGNG0618nobodyさん
2006/04/09(日) 18:42:07ID:???0619nobodyさん
NGNG0620nobodyさん
2006/04/10(月) 03:16:42ID:???使ってみて具合が悪かったら自分でごにょごにょして作成者やメンテしてる人にパッチ送ったり
0621nobodyさん
2006/04/20(木) 15:40:54ID:???httpd.confにApache::Registry等を書き込む方法を説明した
サイト等があれば是非教えていただきたいのですが。
このままだと多分mod_perlが入っていない状態と同じであると思われるので…
0622nobodyさん
2006/04/21(金) 11:54:36ID:???サイトは知らないけど、こんな感じでＯＫ。
但し、Apache2+mod_perl2での例。
LoadFile "c:/Perl/bin/perl58.dll"
LoadModule perl_module modules/mod_perl.so
<Directory "c:/mod/perl/path">
SetHandler perl-script
PerlHandler ModPerl::Registry
Options +ExecCGI
</Directory>
0623nobodyさん
2006/04/21(金) 12:44:01ID:???有難うございます。
しかし、やってみた所、どうもInternal Server Errorが出てしまいます。
Windowsにはパーミッションの概念がないので、
confのどこかがおかしいのは明白なのですが。
状況が分かりにくいと思いますので、上記の修正前のhttpd.confを丸ごと上げました。
もし宜しければ、修正点などを指摘して頂けないでしょうか。
ttp://www.uploda.net/cgi/uploader4/index.php?dlpas_id=0000001608
pass:conf
0624622
2006/04/21(金) 18:19:24ID:???httpd.conf を見ましたが、特にエラーとなる要因は無いと思います。
ただ、
PerlHandler ModPerl::Registry
といった記述が無いので、このままではmod_perlは動作しないと思いますが、
修正後は入れているということですよね？
apachectl -t
で何かエラーが出ますか？
リクエスト時の error.log には何が記録されてますか？
テストしているソースコードは他のmod_perl環境で動作した実績はあるのでしょうか。
0625nobodyさん
2006/04/22(土) 12:41:09ID:???confファイルを見て頂き、大変恐縮です。
上記のスクリプトは修正前なので、実際は何れの<Directory>の中に
PerlHandler等の記述をした上で行います。
apachectlコマンドは、binフォルダ内にもApacheフォルダ内にもexeが存在しないため、
多分ですが、Win32環境では使えないのでは、と思っています。
実際に、既存の<Directory>内に(C:/wwwとC:/www/user/*)
SetHandler perl-script
PerlHandler ModPerl::Registry
を追加してみたものの、今度はWebページすべてが404エラーとなり、
cgiへのパスを入力した所、Internal Server Errorが出ました。
尚、その場合におきまして、error.logには、
cgi-lib.plが@INC内にないというエラーが出ましたので、
早速@INCに当たる部分(C:/Perl/lib/)に、公式より落として入れてみたものの、その後も
[error] [client 192.168.11.2] Attempt to serve directory: C:/www/
のようなエラーが出たまま、cgiファイルは勝手にソースを
ダウンロードさせるような形になってしまいました。
その際にも、相変わらずWebページは404エラーのままでした。
0626nobodyさん
2006/04/23(日) 13:51:13ID:???0627nobodyさん
2006/04/23(日) 13:54:33ID:???print q{Content-Type: text/plain}, map {qq{$_=$ENV{$_}\n}} keys %ENV
という内容のファイルで試してみ。
何か汚そうなコードを動かそうとしているみたいだから。
0628nobodyさん
2006/04/26(水) 19:48:07ID:???0629nobodyさん
2006/04/26(水) 21:28:55ID:???0630nobodyさん
2006/04/27(木) 15:22:10ID:???とりあえずここ嫁。
ttp://perl.apache.org/docs/2.0/os/win32/config.html
0631622
2006/04/27(木) 16:42:02ID:???遅くなりました。
Win32版に apachectl は無いですね。
失礼しました。
何が原因か分かりませんが、状況からすると mod_perlだけでなく、
他の問題も含まれている気がします。
まずは、mod_perlを後回しにして普通の CGIが動くようにディレクティブを設定して、
それから mod_perlに関する記述を入れてはいかがでしょうか。
そんなに複雑な設定をしなくても、すんなりと動いてくれるはずです。
但し、mod_perl に適したソースコードが前提となりますが。
>>630 のリンク先も、かなり参考になるはずです。
0632nobodyさん
2006/04/28(金) 01:25:45ID:???Attempt to serve directory がログに残るのは，SetHandler を記述すると
DirectoryIndex が効かなくなるためです。よって 404 が返るのだと思われます。
で，cgiを動かしたいディレクトリがどこなのハッキリしませんが，c:/www だとすると，
<Directory "c:/www">
Options -Indexes FollowSymLinks +ExecCGI
AllowOverride None
Order allow,deny
Allow from all
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
PerlOptions +ParseHeaders
</Directory>
とりあえずオマケで付いてくる printenv.pl を置いてみて，確認しましょう。
但しこれですと htmlファイルとかも mod_perl の餌食になりますので，
SetHandler以下3行をFilesMatchなんかで括って，拡張子 cgi だけ
mod_perlで動くようにするすると幸せになれるのでは？
0633nobodyさん
2006/04/29(土) 02:42:25ID:???たくさんのレスを頂き大変感謝しています。
御陰様で、やや状況が前進しました。
>>630氏のサイトを参考に設定を行い、>>632氏の指摘通りに
.cgiの拡張子のみに適応するようにしました所、
>>627氏の記述(HTTPヘッダを付け足しましたが)により生成したcgiと、
>>630氏のサイトのprintenv.cgiを正しく表示する事が出来ました。
しかし、>>627氏の仰る通りに、汚いプログラムを動かしているのですが、
どうやらcgi自体がrequireしているファイルを、@incの場所しか読まず、
同階層に存在しているものを、読んでくれない為の様なのです。
何故なら、@incに存在しないファイル(cgi-lib等)が、
require要求を出すCGIと同一の階層に既に含まれているからです。
ちなみに、mod_perlを使わない状態では、
エラーは出る事がなく、きちんと見る事が出来ていました。
どうか、お知恵をお貸しください。
0634nobodyさん
2006/04/29(土) 05:02:27ID:???0635632
2006/04/29(土) 08:38:44ID:???PerlRequire に記述した StartupScript (例では extra.pl) の先頭に，
INC に追加したい Path を以下の様に記述してください。
(Pathはテキトーです，書き換えて下さい)
BEGIN {
use lib qw( c:/www/lib c:/www/cgi-bin/lib );
}
または，cgi の先頭に 上記の use 文のみ記述しても同じです。
これで INCの問題は解決しますが，そもそも mod_perl では cgi 実行時の
カレントディレクトリが cgi の存在するディレクトリになりません。
汚い cgi では File の入出力とかで問題が出るかも？ですので，ファイル名が
相対パスで記述されている部分を絶対パスにするなど，手を打っておきましょう。
Have a nice GW !!
0636632
2006/04/30(日) 01:19:27ID:???635 の use 文は無し無しです。
require を絶対パスで記述して下さい。たとえばこんな感じ。
require 'c:/www/jcode.pl';
しかし，想像するに Perl4 時代の cgi の様な感じがしますね。
結構苦労すると思います。この際，ModPerl::Registry は止めて
ModPerl::PerlRun で妥協するのも有りかもしれません。
0637nobodyさん
2006/05/05(金) 22:48:25ID:2XcXcVrY下記コードをmod_perlが実行できる環境で単純に実行するだけだと Cannot open included file とエラーがでます。
mod_perlで実行するには、どう変更したらよいのでしょうか。
__ HTML __
<html>
<head><title>Test Template</title>
<body>
My Home Directory is <TMPL_VAR NAME=HOME>
<p>
My Path is set to <TMPL_VAR NAME=PATH>
</body>
</html>
__ perl __
use strict;
use HTML::Template;
my $template = HTML::Template->new(filename => 'test.html');
$template->param(HOME => $ENV{HOME});
$template->param(PATH => $ENV{PATH});
print "Content-Type: text/html\n\n", $template->output;
0640nobodyさん
2006/05/06(土) 09:50:32ID:???0641nobodyさん
2006/05/06(土) 13:03:05ID:DaCfpo3Zありがとうございますー。
テンプレートの場所をフルパスで指定しましたらエラーは吐かれなくなりました
＞mod_perlではスクリプトのあるディレクトリがカレントディレクトリになるわけではない。
肝に銘じておきます。
0642nobodyさん
2006/05/06(土) 14:10:03ID:???そんな肝に銘じたりマヌケなことするんじゃなくて、
トラブったときに自分で解決する心がけを身につければよいのでは？
0643nobodyさん
2006/05/06(土) 17:03:35ID:???0644nobodyさん
2006/05/06(土) 17:59:26ID:???Apache::PerlRun + perlcc -B
perlの場合現実的な解の有力候補だと思う。
Apache::PerlRunの欠点をperlcc -Bで補う。
perlccは効果薄いと言われてますが、遅いPCではかなり効く。
http://rintaro.dip.jp/nicky/index.html
メリット
導入容易
対象プログラム多
リソース消費小
デメリット
スピード面では最高ではない。
0646nobodyさん
2006/05/07(日) 11:09:46ID:???バイトコンパイルは俺も試したが確かに効く。
perlccが効かないとされてる記事はどれも単純なバイトコンパイルではないよ。
実行ファイルにまでコンパイルしている。
しかし、
Apache::PerlRun + perlcc -B
これ本当に動くの？
SpeedyCGI + perlcc -Bはバイナリいじれば動いたがコマンドラインオプション一切受け付けなくなった。
0647nobodyさん
2006/05/09(火) 01:34:46ID:???0648nobodyさん
2006/05/09(火) 14:05:03ID:???>perlcc使うくらいなら、Cで書き直せばいいのに。
はあ？
perlcc -Bはただのバイトコンパイルですが。
Emacs Lispのバイトコンパイルと全く同じ。
0649nobodyさん
2006/05/09(火) 14:11:41ID:???痛すぎる。
>644
>perlccは効果薄いと言われてますが、遅いPCではかなり効く。
>http://rintaro.dip.jp/nicky/index.html
読んでみたほうがいいかと。
0650nobodyさん
NGNG0652nobodyさん
2006/05/09(火) 15:00:50ID:???>646
>perlccが効かないとされてる記事はどれも単純なバイトコンパイルではないよ。
>実行ファイルにまでコンパイルしている。
■ このスレッドは過去ログ倉庫に格納されています