私はあなたに助けを求めたいです。当社では、Windows マシンに Bugzilla 4.0 をインストールしています。perl の実行には、現在 ActivePerl を使用しています。
問題は、約 50 人のユーザーが定期的に Bugzilla Web サービスにクエリを行っており、サーバーがこの負荷に耐えられないことです。すべてのリクエスト中に実行されている perl.exe が原因であることがわかりました。サーバーのワークロード (CPU) は、ピーク時に 90% になります。
この問題を経験したことがありますか? パフォーマンスを向上させるために、可能な構成はありますか?
使用しています: Apache 2.2.17 および ActivePerl 5.8.9 b829。私たち(特に私)には大変ご迷惑をおかけしております。
2 に答える
これは、サイトが大きくなるにつれてよくある問題です。また、特に Perl に限定されているわけでもありません。解決策があります。ある人が言及したように、基本的に Apache モジュールとしてインストールされる mod_perl があります。これは、Apache::Registry を介して一種の単純なバージョンで使用することも、各要求フェーズで Apache API と対話するコンポーネントを作成することによって、すべてを行うこともできます。mod_perl でどのようなアプローチを取るにしても、いくつかの共通点があります: これは永続的なプロセスです。つまり、(簡単に言えば) Perl は 1 つのリクエストから次のリクエストまで常駐するため、起動コストを削減できます。CGI スクリプトは、ある程度のクリーンアップとリファクタリングを行わないと、mod_perl に直接移植できないことがよくあります。スクリプトは永続的な環境で実行されるため、たとえば、グローバル変数はリクエスト間でリセットされません。克服すべき「落とし穴」の全リストがあります。そのために、Apache::Registry は、API のプログラミングが直接提供できるパフォーマンス馬力の 100% を提供しないという犠牲を払って、mod_perl 環境で処理するのがいくぶん簡単です。それにもかかわらず、それはかなり良い妥協です。
もう 1 つのオプションは、FastCGI Web サイトで読むことができるFastCGI です。
適切に作成された CGI スクリプトは、ある程度の努力をすれば mod_perl または FastCGI に移植できます。そのため、これらはおそらく最も痛みの少ないアプローチです。一部のスクリプトは、クリーンアップをほとんど行わずに変換できます。他のものは多くの作業を必要とするかもしれませんが、それでも可能です。
幸いなことに、CPAN には、mod_perl または FastCGI の使用を支援する便利なモジュールが多数あります。たとえば、CPAN の Apache::* 階層の下には、mod_perl で動作するように設計された多くのツールがあります。FastCGI に関しては、Catalyst と Mojolicious 関連のモジュールが 2 つを融合させるのに役立つことさえありますが、最後の 2 つの提案はおそらく実際のリファクタリングが必要になるでしょう。
Practical mod_perl が出発点として役立つことがわかりました (O'Reilly の本)。
考察の材料: mod_perl