mod_perlを使おう！
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん
01/11/07 17:42ID:+Gux2iOQ関連リンク等は>2
0511nobodyさん
2006/01/03(火) 02:21:30ID:???どっちでも修正は必ずいるよん。
修正する必要がないように作ってあるものはmod_perlの恩恵を受けられないよん。
0512nobodyさん
2006/01/03(火) 14:53:51ID:???両対応で書いてるけど。
0513nobodyさん
2006/01/07(土) 02:56:13ID:???アパッチが性能向上に励んでいるのに足引っ張りまくり。
mixiがmod_perl使ってせいで重いのは当然だな。
試しに作る分にperlはありだけど、運用するならもっと軽い実装方法とか共同鯖なら実行プロセスのセキュリティのことを考えた方がいいよ。
0514nobodyさん
2006/01/07(土) 09:52:35ID:???このひとPerl vs Ruby vs Python vs PHPスレにも居たJava厨？
0515nobodyさん
2006/01/07(土) 12:43:10ID:???0517nobodyさん
2006/01/08(日) 01:16:19ID:???mod_perl と TOMCAT なら mod_perl の方が速いという結果が出てるけど
ま、CでApacheモジュールとして作り込むのが一番速いだろうけど、
開発コストやセキュリティ的に現実的じゃないしな。
0518nobodyさん
2006/01/17(火) 16:12:00ID:???apacheを肥大させたくないのならfastcgi
少人数でコストを抑えて速度を求めるならmod_perlはグッドチョイスだと思うよ
0519nobodyさん
2006/02/10(金) 12:07:43ID:???エロイ人教えてくれ。
0520nobodyさん
2006/02/10(金) 14:02:17ID:???0521nobodyさん
2006/02/10(金) 16:31:37ID:???0522nobodyさん
2006/02/16(木) 19:42:32ID:???今回、mod_perl2 に手を出してみようと思ったんですが、
mod_perl2 はおろか mod_perl1 も初めてです。
Apache2 を使う都合上、mod_perl2 で開発になるんですが、
色々とサイトを調べても mod_perl2 の情報は少ないのですね…。
みなさんはどこで mod_perl2 の勉強をされたのでしょうか？
というかその前に mod_perl から勉強した方がいいというオチ！？
mod_perl の 2 と 1 の違いもあまりわからない初心者ですが
何か有益なサイトがありましたら教えてください。
とりあえず http://perl.apache.org/docs/1.0/guide/porting.html で mod_perl1 を学んで、
http://modperlbook.org/html/part5.html で mod_perl2 を知ろうかと思ったんですが
英語なので早くも挫折しそうです ＾＾；；；＾＾；＾；＾；＾＾
0523nobodyさん
2006/02/16(木) 20:16:42ID:???0524nobodyさん
2006/02/17(金) 01:59:05ID:???0525nobodyさん
2006/02/17(金) 02:16:31ID:XCO/AQtb0526nobodyさん
2006/02/17(金) 15:52:42ID:???日本語情報が欲しいなら、オライリーのApache拡張ガイドを買った方がいい。
ただ内容がmod_perl1だから、2については本家ドキュメントを読むしかないね。
1と2は結構違うけど、単にRegistryで動かすんなら、
変更があったPerlハンドラに気をつければ、1と大して変わんないよ。
0527522
2006/02/21(火) 18:55:01ID:???レス有難うございました。
あれから色々と調べていますが、
mod_perl1 の文書と mod_perl2 の文書を
行ったりきたりで結構混乱してます。。
（ハンドラがよくわかってないです）
そもそも post/get 関わらずクエリを取る場合、
どのやりかたが一般的なのでしょうか？
1. CGI.pm
2. Apache2::Request;
3. Apache2::RequestRec （これはpostが取れない？？）
また、ファイルのアップロードを受け付ける場合は 1, 2 だけ？？
Apache関連モジュールを使わなくても
CGI.pm で普通にコーディングしたら動いたので、
そのままCGIを組むように作ってもmod_perlの温床に預かれるのでしょうか。
0528nobodyさん
2006/02/21(火) 20:10:21ID:???恩恵があるかどうかは、CGI.pmのソース見てみればわかるよ。
バージョンが古いとだめかも知れないけどね。
0529527
2006/02/21(火) 20:42:11ID:???最新の CGI.pm は mod_perl 環境かどうかで
切り替えて use してますよね。
CGI.pm を使って普通に strict なソースを組めば
（プログラムのパスなどの注意は別として）
問題なく mod_perl2 が使えるって考えで正しいでしょうか？
変に難しく考えすぎてたのかな…
Apache2の設定も
<Files *.pl>
SetHandler perl-script
PerlHandler ModPerl::Registry
Options +ExecCGI
PerlSendHeader On
Order allow,deny
Allow from all
</Files>
この程度です。
0530529
2006/02/21(火) 22:06:48ID:???PerlModule ModPerl::Registry
PerlModule Apache::DBI
#PerlModule CGI
PerlRequire /var/www/lib/startup.pl
<Files ~ "\.pl$">
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
PerlOptions +ParseHeaders
</Files>
いろんなサイトにはExecCGIも書いてあったのですが、
この場合不要ですよね…
0531nobodyさん
2006/02/22(水) 03:05:01ID:???http://perl.apache.org/docs/1.0/guide/config.html
> The Options directive accepts various parameters (options),
> one of which is ExecCGI. This tells the server that the file is
> a program and should be executed, instead of just being displayed like
> a static file (like HTML file). If you omit this option then
> the script will either be rendered as plain text or else it will
> trigger a Save-As dialog, depending on the client's configuration.
調べてみたけど、出力したものをHTMLとみなすために(?)一応、要るのだと思う。
0532530
2006/02/23(木) 16:34:46ID:???有難うございます。やっぱり必要だったのですね…。
コメントアウトしても動いていたので不要なものなのかと思っていました。
ちなみに mod_perl2 で使うモジュールについてなんですが、
ドキュメントで PerlModule と PerlRequire が同義であると知りました。
なので、PerlModule を使わずに全部 startup.pl 内で定義しようと思ったのですが、
use strict; use warning; の定義については効果ないのですね。
（どのスクリプトでも my 使わない変数が使えてしまいました）
CGI.pm とかは、スクリプト内で use CGI; しなくても使えたのですが。
それと、mod_perl2 で使われる標準モジュールがよくわからないのですが、
Apache2.pm は必ずしも必要なのでしょうか？ModPerl::Registry, CGI.pm だけで動作しているのですが、
サイトによっては use Apache2 が必要と書いてあったりします。
（使いたいのは、基本的な関数(exitなど)やサーバ環境変数程度ですが、現状問題なく動いてます）
（CGI.pm あれば事足りるって感じなのかな）
また、exit 関数が自動で ModPerl::Util::exit に割り当てられているようですが、
その場合は use ModPerl::Util; しなくてもいいのでしょうか？
うーん。。アホな質問ですんません。
【環境】
OS: CentOS4.2, Perl: 5.8.5, Apache: 2.0.52, mod_perl: 2.0.2
0533nobodyさん
2006/02/23(木) 17:09:07ID:???0534nobodyさん
2006/02/23(木) 21:49:49ID:???exit関数は、昔はCGI.pmに定義されてたこともあったけど、
今はどうなってるのかさっぱり。
ドキュメントも無いし…。
0535nobodyさん
2006/02/23(木) 22:21:53ID:???何らかのフレームワークに乗っかればいいだけやん。
0536nobodyさん
2006/02/24(金) 12:51:51ID:???0537nobodyさん
2006/03/01(水) 17:15:17ID:???最後にちゃんと $dbh->disconnect(); しないと危険？
0538537
2006/03/01(水) 17:26:08ID:???最初にDBにつないでデータ取ってきてそれをごにょごにょやって
ある条件のときにリダイレクトなりエラーなりをさせたときに、
その前にDBを disconnect するのを忘れちゃうんですよね
0540ヽ(´ー`)ノ ◆.ogCuANUcE
2006/03/01(水) 20:04:52ID:???危険つーか、新しくユーザからリクエストがある度にコネクションを開いて
そのままになったら、いつかは DB 側の限界が来てエラーになる…かも。
自前でコネクションプーリングしてれば別だけど、disconnect() しとけば？
> その前にDBを disconnect するのを忘れちゃうんですよね
……。
0541537
2006/03/01(水) 20:28:51ID:???ですよね…
ちなみに、mod_perl + DBI のときは PrintError と RaiseError はどうしてるんですか？
RaiseError => 1 に関わらず、DB接続後にdieされたときには
mod_perlでも自動でdisconnect されるんでしょうか？
…であれば、die しているところでは明示的にdisconnect不要ですよね
0542nobodyさん
2006/03/02(木) 00:14:54ID:???dieで閉じるのも変数のスコープから外れてこれが動くだけでしょ。
0543ヽ(´ー`)ノ ◆.ogCuANUcE
2006/03/02(木) 00:37:49ID:???DBI のマニュアル読んできた。デフォルトでは DESTROY が動けば閉じてくれる
ようだ。InactiveDestory => 1 だと DESTROY でも閉じないようだよ。
スコープから抜けたりして DESTROY が動けば閉じられるけど、mod_perl 下では
そうじゃないケースも簡単に作れてしまう。
やっぱり disconnect() するか Apache::DBI を使う方がいいと思う。
> ちなみに、mod_perl + DBI のときは PrintError と RaiseError はどうしてるんですか？
エラー受けたら再試行やロールバック。
ユーザにごめんなさいするページを表示して管理者にメール。
ログ見てデバッグ。
0544nobodyさん
2006/03/02(木) 11:29:14ID:???Apache::DBI を使えば、例えperlのソースに disconnect() があってもそれは何もしないってマニュアルで見ました。
ってことは apache のプロセスが終了したときに自動で disconnect() されるんかな？
一度、Apache::DBI で組んでたんですけど、コネクションがいくつか立ち上がってるときに、
コマンドラインでテーブルを drop しようとすると、何もエラーが出ずに返ってこなくなりました。
恐らく drop する時にはそのテーブルを参照しているコネクションが閉じられてないとダメなんでしょうね。
（apache を再起動してコネクションを開放したらdrop できました。）
ただ、レコードの追加・更新・削除はコネクションあっても問題なくできて、
apache 側でも更新されたレコードはすぐに参照できたんですよね。
その辺がしっくりこなくて、Apache::DBI を使うのをちょっとやめようかなという気になってしまってました。
でも逆に DBI を使うと、ちゃんと disconnect() しないとコネクションが張られ続けるって問題が…
（エラーチェックはどっちにしてもちゃんとやれってことですね。）
0545ヽ(´ー`)ノ ◆.ogCuANUcE
2006/03/02(木) 16:14:08ID:???> コマンドラインでテーブルを drop しようとすると、何もエラーが出ずに返ってこなくなりました。
……。
0546544
2006/03/02(木) 16:47:20ID:???なんか不慣れ丸出しですんません。
最初コネクションが原因だとわかるのに数時間はまりましたｗ
Webを放置すると、同じテーブルを再構築したりしたのに現象がおきなかったので。。
（そりゃ、コネクションの問題であれば一定時間経過しちゃえば現象なくなりますわ）
とりあえずApache::DBI使ってdisconnectをまかせてみます。
0547nobodyさん
2006/03/08(水) 07:55:23ID:???たまにソースを変更した箇所が反映されていなかったりエラーが出たりして
結局htttpd自体をリロードするハメになってしまいます
これを回避する方法はありますか？
0548nobodyさん
2006/03/08(水) 18:08:50ID:???{
my $hoge;
}
my $hoge;
のようなことをやると、以下のエラーが出たり出なかったりします。
Can't use global $0 in "my" at (eval 114) line 1, near "local $0 "
BEGIN not safe after errors--compilation aborted at xxx.pl line xx.
※line xx の行は「use strict;」 と書かれています。
mod_perl ではたとえブロックが違っていても、
同じ変数名は my で定義できないのでしょうか？
0550nobodyさん
2006/03/10(金) 00:53:06ID:???理解出来ないならおまいにmod_perlは無理。業者に丸投げしとけ。
0551nobodyさん
2006/03/10(金) 08:12:24ID:???随分前にmod_perl＋Apache::Reload+CDBIだけど同じことに悩まされてぐぐったら
ttp://hori-uchi.com/archives/000247.html
こういう事らしい
mod_perl2＋Apache2::Reloadで確認してないけど同じなのでは？
適当でごめんね
>>548
＞Can't use global $0 in "my"
ってエラーにでてるじゃん
マジック変数$0をmyすんなって怒られてるんでしょ
mod_perlは関係ナス
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だと落ちる原因わかったんですか？
■ このスレッドは過去ログ倉庫に格納されています