私はこの記事を読んでいます：
http://www.modrails.com/documentation/Architectural%20overview.html#web_app_models
Phusion PassengerがApache2を拡張してアプリケーションサーバーとして機能する方法について説明します。 HTTP要求が入ると、Phusion PassengerモジュールはPhusion Passengerが提供するアプリケーションがその要求を処理する必要があるかどうかを確認します。その場合、モジュールは必要に応じてアプリケーションのプロセスを生成します。要求をアプリケーションプロセスに渡し、応答をクライアントに返します。ビルドプロセスを改善するために、Passengerはビルドサーバーとして機能し、Ruby on Railsフレームワークコードとアプリケーションコードをメモリにキャッシュします。
これにより、新しい要求が入るたびにプロセスが生成されたときにキャッシュされたコードを参照し、プロセスをすばやく生成します。しかし、キャッシュの生成はhttpリクエストに比べてまだ高価です。したがって、アプリケーションプールが使用されます。アプリケーションプールが何であるかを理解していません。これが言う内容です：
結果のアプリケーションインスタンスはアクティブのままで、そのハンドルはこのプールに保存されるため、後で各アプリケーションインスタンスを再利用できます。その結果、パッセンジャーは平均的なケースパフォーマンスに非常に優れています。
「生き残る」と「このプールに保存されたハンドル」とはどういう意味ですか？私の考えでは、キャッシュは後でデータを維持することです。だから違いが何であるか理解していません。
答え1
これにはバイナリのオン/オフの状況はありません。連続体です。
連続体の一つの極端は古いコンピュータグラフィックス画像処理Webプログラミングモデル：Webサーバーは、着信した各要求を処理するためにアプリケーションを再起動します。要求を処理した後、アプリケーションは終了します。毎回アプリケーションを再起動する必要があるため、再構築する必要があります。申請状況要求に従って。これは時間とデータスペースの両方で高価です。
そのため、時間の経過とともにコストを削減するために多くのオプションが作成されています。
クイックCGICGI モデルを使用しますが、初めて起動した後も CGI プログラムをアクティブに保ち、常に新しい要求を提供します。これにより、CGIプログラムを再起動するコストを回避できるだけでなく、アプリケーションがRAMに状態を保存できるようになります。
mod_{perl,php,ruby,...}実際のアプリケーションインタプリタをWebサーバーインスタンスにインポートするこれらのシステムは、FastCGIと同じことを行う傾向があります。つまり、各スクリプトをロードしてそれを特定のタイプにコンパイルした後です。バイトコード、すべての操作をやり直す必要なく、新しい要求のみを提供します。あなたが話しているシステムは
mod_fooそれよりも高いレベルのシステムで、アプリケーション全体の論理モデルをRAMに保持するため、各要求に対して再生成する必要がはるかに少なくなります。mod_fooこれがあなたが得る基本的な振る舞いとまったく異なることを言うことはできません。しかし、重要なのは定性的な違いではなく、定量的な違いです。Phusion Passengerの目標を理解するのに役立つ次のステップは、すべてを単一の長期実行アプリケーションインスタンスで実行することです。これはWebサーバーベースのアプローチです。アランド働く、窒素など。 Apacheベースのアプリケーションの仕組みを比較するには、2番目のリンクを参照してください。
私は多くのJavaベースのアプリケーションサーバーが同じように動作すると思います。
結論は、これらすべてが最適化、スピードのためにRAMとランタイムの複雑さを取引するゲームであるということです。
答え2
「keep-alive」という用語と「ハンドルがこのプールに保存されています」という用語は、キャッシュとは異なることを意味します。
隠れ家
キャッシュは、検索コストの高いデータを後で再利用できるようにすばやくアクセスできる場所に保持するメカニズムです。次のようなさまざまな場所で使用されていることがわかります。
- データベースから何かを探す
- サーバーのIPアドレスを確認してください。
- ハードドライブのファイルにアクセス
プーリング
Phusion Passengerのドキュメントで「キープアライブ」と言うのは、アプリケーションの起動にかかる時間を節約するために、アプリケーションを無期限に実行したままにすることです。
Web要求を処理するときにアプリケーションができるだけ応答したいと思います。アプリケーションの起動に数秒かかり、データベースからデータの要求に数秒かかる場合は、レスポンシブWebアプリケーションを作成できません。
だから私たちがしたことは、接続を許可し、アプリケーションの複数のインスタンスを常に実行状態に保つ軽量フロントエンドを構築し、フロントエンドが次のことを行うことです。
- すでに実行されているアプリケーションインスタンスの1つに着信接続を割り当てます。
- この実行中のインスタンスから結果を取得する
- クライアントに結果を返す
- 実行中のアプリケーションインスタンスを「処理準備完了」状態に戻します。
はい
私はいくつかの金銭登録機がある食料品店の例を使いたいと思います。各チャンネルはアプリケーションサーバーのインスタンスであり、各チャンネルは一度に1人のユーザーしか処理できませんが、一緒に使用すると複数のユーザーにサービスを提供できます。
見たらRuby用Mongrel HTTPサーバーこれは、ほぼ同じ方法でプールで実行するように設計されています。
広く使用されている構成の1つは、複数のMongrelインスタンスでmod_proxy_balancerを使用してApache HTTP Server 2.2をロードバランサーとして使用することです。各 Mongrel インスタンスは、mongrel_cluster 管理ユーティリティーによって構成された別々の TCP ポートで実行されます。最近まで、Twitterはこのような構成のよく知られた例でした。
Mongrelは追加のWebサーバーを必要とせずにRuby on Railsベースのサイトを提供できますが、シングルスレッドアプリケーションとして、この設定は軽量負荷以外には適していません。