私の Web プロジェクトが PSGI を使用した実装の候補であるかどうかを判断しようとしてきましたが、この段階ではアプリケーションにどのような効果があるかわかりません。
私はすべての大騒ぎを本当に理解していません。私には、PSGI は異なる Apache モジュール間でアプリケーションを移動できる共通のインターフェースを提供するフレームワークのように思えます。たとえば、アプリケーションを mod_perl で実行するものから fastcgi に簡単に移行し、両方のオプションで実行するためのアプリケーション サポートを提供します。
そうですか、それとも何か見逃しましたか？
私と私が所属するチームは、アプリケーションを開発するだけでなく、サーバーのメンテナンスとセットアップも行っているため、fastcgi、cgi、および mod_perl で実行できることの価値はわかりません。 mod_perl だけで問題ありません。
PSGI の機能を誤解していますか、それとも単に私のプロジェクトに適していないのでしょうか?
Apache ビットは忘れてください。これは、Web サーバーの選択の関連性が低くなるようにアプリケーションを作成する方法です。$work では、Apache2 にアップグレードした後、アプリが非常に高い CPU 負荷で実行されていることを発見した後、Plack/PSGI に切り替えました。さまざまな Apache 構成のベンチマークと NYTProf'ing では理由を特定できませんでした。私たちのために。
現在、すべてが Apache 構成ではなく、PSGI アプリ (URL の書き換え、静的コンテンツ、有効期限ヘッダーなど) によって 1 か所で処理されるため、a) Perl であり、b) 標準の /t/ スクリプトを介して簡単にテストできます。また、私たちのテストでは、基本的なアプリ自体だけでなく、ユーザーが見ているものを正確にテストしています.
あなたがApacheとmod_perlに満足しているなら、それはあなたには関係ないかもしれません、そして私は他の人がもっと良い答えを与えることができると確信しています.それ自体。テストの容易さと、ModRewrite や友人と格闘するのではなく、Data::Dumper に固執して何が起こっているかを確認できることは、大きなメリットです。
chromatic による最近のブログ投稿、Why PSGI/Plack Matters (Testing)から借りると、次のようになります。
Python の WSGI と Ruby の Rack から借用して Perlish にしたのは良い考えです。これは、Web アプリケーション開発のパターンを単純に形式化したものです。アプリケーションへのエントリ ポイントは関数参照であり、出口ポイントはヘッダー情報と応答本文のタプルです。
それでおしまい。それは可能な限り単純であり、その単純さはそれを学びたい多くの人々を欺きます.
重要な利点は、同上である。、
Plack アプリケーションが与えられた場合、あたかもデプロイされたかのようにアプリケーションをテストするために、Web サーバーに (ローカルであっても) デプロイする必要はありません… Plack とTWMP (およびPlack::Test ) は、明確に定義された Plack パターンを使用して何かを作成します。以前は難しかったことが、驚くほど簡単になりました。彼らは最初ではなく、最後にもなりませんが、Plack の価値を実証しています。
回答を書き始め、50行後に削除しました。なぜ PSGI が非常にクールなのかを (要するに) 説明できないからです。私も PSGI は初めてですが、以前の apache/mod_perl 時代と同じように、zilion の操作ははるかに簡単になりました。
私はあなたに次のアドバイスをすることができます：
ps: ここに "Perl Oscar" のようなものがあれば、きっと MyiagavaSan を指名するでしょう。:)