mod_perl 環境下でやっちゃダメなものをいくつか。
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:
大規模なeコマースサイトを Apache と mod_perl で構築する
この文書は Perl.com: Buildling a Large-scale E-commerce Site with Apache and mod_perl を翻訳したものです。2001年に書かれた文書であり、Apache/mod_perl/CPAN モジュールなど現在の状況にはそぐわない部分もある可能性があります。 大規模なeコマースサイトを Apache と mod_perl で構築する よくある神話 Perl はセーブする アプリケーションサーバの撰択 ケーススタディ: eToys.com Apache::PerlRun による救済 新たなアーキテクチャの計画 2000年のクリスマスを切り抜ける アーキテクチャ プロキシサーバ アプリケーションサーバ 検索サーバ ロードバランスとフェイルオーバー コード構造 キャッシング セッショントラッキング セキュリティ 例外(Excepti
Perl OO におけるオーバーヘッド - naoyaのはてなダイアリー
フレームワークを考えるにあたって、気になる部分のベンチマークを取ってみた。 ポイントは次の３点。 関数の呼び出し方法： Class::func() と Class->func() 形式 クラスを継承した場合のペナルティ： Class->() と SuperClass->() 連想配列への直接アクセスと、アクセサ経由のアクセス Perl における関数型の実装と OO の実装で、関数呼び出し/メソッド呼び出しでどの程度のオーバーヘッドの差があるかをベンチマークした結果。勉強になります。結果としては関数型に対して OO の方が数倍遅い、という結果。 それで、結論の方なのですが 本来なら、アプリケーションより下位にあたるライブラリ関連は、オブジェクト化されて mod_perl 上で共有されるメリットはあるかもしれないが、アプリケーションの上位にあたるフレームワークは、mod_perl 上で共有され
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
