Plack/Starman を使用して小さな Catalyst Web アプリをデプロイしようとしています。すべてのドキュメントは、これをnginxと組み合わせて使用したいと示唆しているようです。これにはどのような利点がありますか? ポート 80 で直接 Starman を使用しないのはなぜですか?
3 に答える
特に nginx である必要はありませんが、いくつかの理由から、アプリケーション サーバーにプロキシする何らかのフロントエンド サーバーが必要です。
ポート 80 でフロントエンド サーバーを実行しながら、通常のユーザーとして、高いポートで Catalyst サーバーを実行できるようにします。
ダウンロード中に perl プロセスを拘束することなく、静的ファイル (画像、JS、CSS などの通常のリソース、および X-Sendfile または X-Accel-Redirect を使用したいあらゆる種類のダウンロード) を提供するため.
Edge Side includes などを含むより複雑な構成に移行したい場合や、memcached または mogilefs (両方とも nginx が実行できること) から Web サーバーを直接提供する場合、または負荷分散 / HA 構成に移行したい場合に、作業が簡単になります。
#plack でこの質問をしたところ、@nothingmuch から次のような回答がありました (書式を追加しました)。
nginx を使用すると、負荷分散/フェイルオーバー タイプのものを設定できます。サイトが小さい/シンプルな場合、やり過ぎかもしれません。
スターマンの欠点については知りません。おそらく、静的ファイルに多くのヒットがある場合、nginx はそれらを処理するために使用する CPU/メモリが少なくなりますが、一般的な Web アプリではそれほど重要ではありません。ただし、大量のダウンロードは、静的ファイルのダウンロードのために Starman ワーカーを拘束する可能性があります。(おそらく、sendfile ではそうではありません。) 私が思いつくのはこれくらいです。
...ダウンタイムなしでアップグレードを行いたい場合は、フェイルオーバー設定が便利です。(古いバージョンは「失敗」します。)
もう 1 つの理由は、軽量のフロントエンド サーバー (Apache でさえ問題ありません) は、典型的な Starman プロセス (数 MB 対数十または 100 MB 以上) よりも接続あたりのメモリ消費量がはるかに少ないことです。接続はしばらく開いているため、特にキープアライブ接続を使用する場合は、はるかに少ない RAM で多数の同時接続をサポートできます。プロキシするフロントエンド サーバーのバッファ サイズが、バックエンドから通常の HTTP 応答をすぐに読み込むのに十分な大きさであることだけを確認してください。その後、バックエンドは次のリクエストを自由に処理できます。