問題タブ [mod-perl]

たとえばmod_php、代わりに使用する方が安全php-cgiですか? それともmod_perl、従来の の代わりに使用する方が安全cgi-scriptsですか?

私は主にセキュリティの問題に関心がありますが、大きな違いがある場合は速度が問題になる可能性があります。

AppleまたはRedHatの組み込みApacheを使用したいのですが、Perl5.10とmod_perlを使用したいと思います。これを達成するための最も邪魔にならない方法は何ですか？ベンダーのApache、dav、phpなどの無料のセキュリティパッチの利点が欲しいのですが、使用するPerlのバージョンと@INCパスに何があるかについては非常に気にしています。自分のmod_perlをコンパイルしてもかまいません。

デフォルトのvanilla Leopard Apache 2の下にmodperlをインストールしようとして失敗しました.オンラインで見つけることができるのはこれのバリエーションだけです:

可能であれば、MacPorts や Fink に依存したくないのですが、デフォルトの Apache 2 インストールで動作するようにできれば、おそらく問題ありません。

データベースの再起動時にセグメンテーション違反が発生し、古い接続を使用しようとする webapp があります。下で実行するgdb --args apache -Xと、次の出力が得られます。

ドライバーとデータベースがすべて最新であることを確認しました ( DBD::mysql 4.0008、MySQL 5.0.32-Debian_7etch6-log)。

厄介なことに、簡単なスクリプトではこれを再現できません。

これにより、次のようになります。

これは正しく動作し、リクエストが失敗した理由を教えてくれます。

私を悩ませているのは、それがすべきではないセグメンテーション違反であるということです。アプリ全体 ( DBIx::Classを使用) が実行されている場合にのみ発生するように見えるため、テストケースに減らすのは困難です。

これをデバッグするにはどこから始めるべきですか? 他の誰かがこれを見たことがありますか？

UPDATE : mod_perl の下にあることは赤いニシンであることがさらに示されました。これを単純なテスト スクリプトにまとめたので、DBI メーリング リストに投稿しました。回答ありがとうございます。

私はPerlで書いているフレームワークのパフォーマンスをベンチマークしてきましたが、既存のコードベースに比べて1秒あたりのリクエスト数が50％減少しています（手続き型スパゲッティコードからOOP MVCフレームワーク）。

アプリケーションはmod_perlで実行されており、 Mooseとすべてのフレームワークコードをstartup.plスクリプトに追加しました。これにより、1秒あたりのリクエスト数が2倍になりました。この数をさらに増やして、既存の量にできるだけ近づけることを目指しています。これは時期尚早の最適化であるという議論がありますが、修正してパフォーマンスにどのように影響するかを確認したいいくつかの明白な非効率性があります。

ほとんどのフレームワークと同様に、構成ファイルとディスパッチャーがあります。構成部分はConfig::Generalによって処理されるため、構成ファイルをアプリにロードするには、少しのIOと解析が必要です。ここで私が目にする最大の問題は、入ってくるすべてのリクエストに対してこれを行っていることです。

私のアプリでDevel::Dprofを実行すると、Mooseではない主要な低速ポイントの1つとして、Config :: General::BEGINと関連するIOモジュールの束が示されます。だから私がやりたいこと、そして後から考えるともっと理にかなっているのは、mod_perlの永続性とstartup.plコンパイルのものを利用して、サーバーの起動時に一度だけ構成ファイルにロードする作業を行うことです。

問題は、これがどのように機能するかについて私があまりよく知らないということです。

現在、各プロジェクトには、かなり無駄のない、次のようなPerlHandlerブートストラップクラスがあります。

MyApp.pmは、次のコードを持つフレームワークProjectモジュールを継承します。

コンパイル時にのみこれを行うには、ブートストラップとプロジェクトの両方のベースモジュールを変更する必要があります（私は思います）が、どのような変更を加えれば、コードを適切で無駄のないものに保つことができるかについてはかなりわかりません。誰かが私をここで正しい方向に向けることができますか？

アップデート

ysthの回答で説明されているように、各プロジェクトモジュールアプローチでBEGINBLOCKを試しました。だから私は今持っています：

この迅速な変更だけで、1秒あたりのリクエスト数が50％増加し、構成ファイルが修正する価値のある主要なボトルネックであるという私の考えを確認しました。私たちの股間の古い開発マシンのベンチマーク値は60rpsであり、この変更だけで私のフレームワークは30rpsから45rpsになりました。Mooseが遅く、コンパイル時間がヒットしていると言う人のために..起動時にすべてのMooseコードをコンパイルすると、構成ファイルを事前コンパイルしたときと同じ（50％）増加しました。

私が今抱えている唯一の問題は、同じConfig :: General-> newコードがすべてのBEGINブロックにあり、構成ファイルへのパスのみが異なるため、これがDRYプリンシパルに違反することです。これを制限するためのいくつかの異なる戦略がありますが、この変更の結果を投稿したかっただけです。

私はPerlでWebアプリを開発しており、必要に応じていくつかのCを使用して、いくつかのヘビーデューティな数値処理を行っています。これまでの主な問題は、mod-perl、mod-fastcgi、またはその両方を使用してスクリプトを実行する必要があるかどうかを判断しようとすることです。各 mod の長所と短所を分析するのに苦労しているためです。

誰でも要約を投稿したり、比較情報や例を含むいくつかの推奨事項を見つけることができるリンクを提供したりできますか?

私は Apache 2 を使用しています。.pl ファイルを「cgi-script」として処理する方法は知っていますが、mod_perl の方がおそらく高速です。mod_perl のビルドとインストールは成功しましたが、.pl ファイルが (cgi スクリプトとしてではなく) mod_perl によって処理されるように、httpd.conf を変更するにはどうすればよいですか?

さて、私は mod_perl で Dispatcher をセットアップしようとしていますが、何が間違っているのかよくわかりません。問題が私の mod_perl 構成にあることはかなり肯定的です。これが私が関連していると思うものです：

Apache ディレクトリ構成

注: ACD::Dispatch は acd/ACD にあります。

ACD::ディスパッチ

そしておそらく最も重要なのは、Apache エラーです。

助けてくれてありがとう！

更新:これをApache構成に追加する必要がありました:

DBIx::Class を使用して mod_perl で CGI::Application を使用しており、インスタンス化時に新しい dbic スキーマを定義する新しいようなものを使用したいと考えています。これまでのところ、私はそれを機能させることができませんでした。私がたどり着いた最も近いものは、新しいオブジェクトを返す connect() メソッドを持つスーパークラスですが、私はそれが既に接続され、インスタンス化されていることを望んでいます。

どんな考えでも本当に感謝します。

ありがとう！

注: わかりましたので、明らかにまだ助けにはなりませんが、当面の間、DBIx::Class を遅延インスタンス化するアクセサを作成したので、少しは改善されるかもしれません。それを確認してください：

そしてもちろん、それを使用するには、次のようにします。

mod perl を使用してアプリケーションを開発しています_が、コードを変更するたびにサーバーを再起動するのは非常に面倒です。_ライブサーバーに使用する予定があるため、開発には引き続き mod perl を使用したいと思います。これを行う方法についてのドキュメントには何もありませんでした。

考え？