mod_perl 2.0 のサーバ起動にまつわる文書を読み込んでいました。 サーバスタートアップスクリプトは,1.0 時代のドキュメントでは「PerlRequire」記述子で読み込むように書かれていることが多いが,実行される時点が中途半端。なので,PerlPostConfigRequire を使う方が吉。もし設定ファイル自体で Perl の機能を利用しているのであれば(普通そこまでコアなことやらなくて済むんだけど),PerlConfigRequire を使うとサーバ設定フェイズ(すなわちかなり早い段階)で実行される。 Apache 2.x では,graceful restart がうまくいくことの確証を得るために,一度サーバ設定フェイズが終わると,Apache 自身を再起動する。ということは,サーバ起動時に,スタートアップスクリプト等は 2 回実行される。このことで困るってことはたいていな
前のエントリー の続き。 速さ重視のウェブサービスってわけじゃないからこだわらずに CGI モジュールを使えばいいと思って該当箇所を見てみたところ、 require Apache::Request; $app->{apache} = $param{ApacheObject} || Apache->request; $app->{query} = Apache::Request->instance($app->{apache}, POST_MAX => $app->config('CGIMaxUpload'));といった感じで Apache::Request を呼ぶ作りになっていたので、簡単な patch を書いてみた。 セットアップ → 日記を書いて保存するところまで動作確認してます。 http://bonnu.heteml.jp/MT-App-MP2.diff --- lib/MT/Ap
Debugging and Profiling mod_perl Applications Feb 9, 2006 by Frank Wiles Because of the added complexity of being inside of the Apache web server, debugging mod_perl applications is often not as straightforward as it is with regular Perl programs or CGIs. Is the problem with your code, Apache, a CPAN module you are using, or within mod_perl itself? How do you tell? Sometimes traditional debugging
10分で、といいながらたぶん mod_perl と Apache2 をビルドするのに 10 分以上かかるという罠。まあいいや。以下のやり方で Linux、MacOSX どちらでもちゃんと動くと思われます。 まず、mod_perl 2.0 のインストール。DSO でもいいけど、ここでは Apache にスタティックに組み込みます。 インストールディレクトリは /usr/local/httpd_mp2 に。 MPM は prefork。perl を thread 有効でビルドしてるなら mpm=worker でもいいと思います。 $ wget http://perl.apache.org/dist/mod_perl-2.0-current.tar.gz $ wget http://www.apache.org/dist/httpd/httpd-2.0.55.tar.gz $ tar zxvf
mod_perl 2 が Stable リリースになって気がつけば半年以上経った様子。はてなではこれまで mod_perl 2 は mod_perl 2.0RC-4 (1.99) とかを使ってましたが、ぼちぼち 2.0 にちゃんと移行した方がいいかなと、重い腰を上げつつ作業してます。 現在、mod_perl には互換性のない三つのバージョンが存在してます。 mod_perl 1.0 (1.29) mod_perl 1.99 mod_perl 2.0 (2.0.2) 1.0 は Apache 1.3 の API に対応している mod_perl、1.99 と 2.0 は Apache 2.0 API に対応している mod_perl です。Apache 2.0 がそれまでのバージョンとの API の互換性を捨ててアーキテクチャの見直しが行われたのをきっかけに、mod_perl も後方互換性を
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
今まで知らなかったんだけど。mod_perl2 の Apache2::Const (1.99 は Apache::Const) の Apache::OK は 200 ではなく 0 を返す。ハンドラから 200 を返した場合は Internal Redirection が一回動いて、Apache 組み込みの 200 画面 (OK とかでるやつ) を返す。 はてなフレームワークが mod_perl と密結合してて嫌んな感じだったので、それを分離するために Apache2::Const を使わずにステータスコードを生の数字で扱うようにしたら、この Internal Redirection が起こってはまってしまいました。200 のときは 0、というか Apache::OK を返さないと、コンテンツの後ろ側に Apache 組み込みの 200 画面がおまけでついてきます。 てっきり Apache:
巷で超高速 Web サーバとして話題になっている lighttpd を試してみました。lighttpd に関する日本語ドキュメントは非常に少なく、ちょっと込み入った設定ファイルの記述方法とかの解析に手間取りました。 lighttpd のコンセプトは、「セキュアで省メモリで高速に動作し、柔軟性もある」なのですが、「lighttpd 公式サイトのベンチマーク結果」や「UnknownPlace. - Catalyst ベンチ」で簡単な Catalyst - Hello.cgi のベンチマークが公開されているとおり、Apache 1系、Apache 2系よりも高速に動作するようです。特に static なページの処理は Apache の 2〜3 倍程度は高速に処理できるみたいです。 また注目すべき点として、Apache + mod_perl よりも lighttpd + FastCGI の方が1割
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
use と require の話、まだ引っ張るのかよって感じですがもうちょっとだけ。del.icio.us で typester 氏からコメントがありました。 requireだけでも、startup.pl のような使い方すればいいよね? んで、一瞬「そうか、startup.pl で全部 reuiqre すればいっしょなのか」と思ったんですがよく考えてみると、その場合 reuqire でロードされるのって結局 startup.pl に書いたファイルだけですよね。 この方法だと、XML::Atom みたいに中で色々使ってるモジュールとかは、その中の実装を考えて全部 require する必要が出てきます。ソースの require な部分を舐めて require するようなロジックを startup.pl に実装するってのも変な話だし。ということでやっぱり use だよなあと。 勘違いかも。 そう
mod_perl 環境下でやっちゃダメなものをいくつか。 exit システム関数 正確には CORE::exit ですけど、実行すると現在の Apache プロセス(nobody)が落っこちます。 当然 root の Apache は子プロセスを立ち上げなおすんで 余分なシステム負荷が掛かりますし、mod_perl のメリットである キャッシュ効果が得られない=普通のCGI実行より鈍足になるという、 なかなか致命的な結果になってしまいます(^^; これを避けるために、mod_perl 環境下では exit() 関数 が 定義されてるので、必要な場合には必ず丸括弧をつけませう。 ○ exit( 0 ); × exit 0; 同じことが、die システム関数 にも言えます。こっちは素直に 「use Carp」して「croak 関数」で代替したほうが安全だと思う。 #eval の中で CORE:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く