22

最近、Perl Web アプリケーションを実行するための非常に一般的な選択肢は、リクエストを FastCGI デーモンまたは PSGI 対応 Web サーバー (Starman など) にプロキシする nginx Web サーバーの背後にあるようです。

なぜ一般的にこれを行うのかについて多くの質問があり (egなぜ Catalyst/Plack/Starman で nginx を使用するのですか? )、答えはどちらの場合にも当てはまるようです (例: nginx が静的コンテンツを提供できるようにする、アプリケーションを簡単に再起動できるようにする) 。サーバー、負荷分散など)

ただし、FastCGI とリバース プロキシ アプローチの使用の長所と短所に特に関心があります。Starman は、最速かつ最高の Perl PSGI アプリケーション/Web サーバーであると広く考えられているようです。どちらのアプローチもサポートしているようです:

  • UNIX ドメイン ソケットと TCP ソケット
  • フォーク/プロセス マネージャー スタイルのサーバーと非ブロッキング イベント ベース (AnyEvent など) サーバー。
  • シグナル処理/グレースフル リスタート
  • PSGI

同様に、どちらのオプションの nginx 構成も非常に似ています。

では、なぜどちらかを選択するのでしょうか。

4

2 に答える 2

17

リバース プロキシのセットアップ (たとえば、nginx が HTTP リクエストを Starman に転送する) には、次の利点があります。

  • バックエンドサーバーに直接アクセスできるため、デバッグが少し簡単です。

  • バックエンド サーバーをスケーリングする必要がある場合は、フロントエンド (静的サービス) HTTP とバックエンドの間で pound/haproxy のようなものを簡単に使用できます (Zope はしばしばそのように展開されます)。

  • 非常に簡単にバイパスできるため、何らかの外向きのキャッシング リバース プロキシ (Varnish や Squid など) も使用している場合は、便利なサイドキックになる可能性があります。

ただし、次の欠点があります。

  • バックエンド サーバーは、フロントエンド サーバーのアドレス (通常は localhost) しか表示されないため、実際の発信元 IP を把握する必要があります。HTTP ヘッダーでクライアントの IP アドレスを見つけるのはほとんど簡単な方法ですが、それを理解するのは難しいことです。

  • 通常、バックエンド サーバーは元の「Host:」HTTP ヘッダーを認識しないため、ローカル リソースへの絶対 URL を自動的に生成できません。Zope は、バックエンドへのリクエストに元のプロトコル、ホスト、およびポートを埋め込む特別な URL でこれに対処しますが、これは FastCGI/Plack/... とは関係ありません。

  • フロントエンドは、たとえば FastCGI でできるように、バックエンド プロセスを自動的に生成することはできません。

あなたのお気に入りの長所/短所を選んで、あなたの選択をしてください;-)

于 2011-03-04T23:34:42.397 に答える
1

HTTP はほとんどのシステム管理者によく理解されており、デバッグも簡単です。ほとんどの場合、何らかのリバース プロキシが既にデプロイされているため、アプリケーションを数秒で起動して実行するために、その構成に別の構成スタンザを追加するだけでも簡単です。両方の設定で速度の違いをテストしたことはありませんが、その領域で問題が発生したことはないので、それほど悪くはありません.

于 2010-12-17T11:31:24.023 に答える