実行する必要があるコア ASP.NET アプリケーションが 3 つあります。IIS 7.5 構成をミラーリングした 2 台の Windows Server 2008 R2 サーバーと、トラフィックを転送するロード バランサー、および状態サーバーとなる別のサーバーをセットアップしています。これですべてのセットアップと動作が完了しました (まだ本番環境ではありません)。
約 120 のクライアントがあり (さらに増え続けています)、現在のセットアップでは、各クライアントが IIS ルートから (.NET アプリケーションとして) 独自の仮想ディレクトリを取得します。仮想ディレクトリ アプリケーションは、独自の web.config が存在するディスク上のディレクトリを指し、接続文字列や一部のコア アプリケーション パラメータなどを格納します。次に、各クライアントのアプリケーションから離れて、3 つのコア ASP.NET アプリのそれぞれに対応する仮想ディレクトリ アプリケーションがあります。だから、このようなもの：
/ (IIS root)
/client1 => c:\inetpub\clients\client1
/app1 => c:\inetpub\applications\app1\current
/app2 => c:\inetpub\applications\app2\current
/app3 => c:\inetpub\applications\app3\current
/client2 => c:\inetpub\clients\client2
/app1 => c:\inetpub\applications\app1\current
/app2 => c:\inetpub\applications\app2\current
/app3 => c:\inetpub\applications\app3\current
「現在の」ディレクトリは、使用されている現在のバージョンへのシンボリック リンクです。
このセットアップにはいくつかの利点があります
- .NET セッション、アプリケーション、および認証情報の自動分離。アプリケーション間の汚染やセキュリティの問題が発生する可能性はゼロです (たとえば、client1 が URL を変更して client2 を表示するなど)。
- web.config の自動継承により、各クライアントの構成ファイルをディスク上で検索する必要がなくなります。設定は「うまくいく」。
- 各クライアントは、独自のアプリケーション プールを持つように構成することができます (実際に構成されているため、1 つのクライアントが他のユーザーにパフォーマンスの問題を引き起こすことはありません)。
短所:
- クライアントごとに 1 つのアプリ プールを使用すると、メモリのオーバーヘッドが大きくなります
- 各アプリケーション インスタンス (/client1/app1、/client1/app2、/client2/app1 など) は、「実際の」アプリケーションが 3 つしかないにもかかわらず、ASP.NET によって個別にコンパイルされます。
- アプリ プールのウォームアップ時間のオーバーヘッドがあります。1 つのクライアントがサーバーにしばらくアクセスしていない場合、最初のヒットはワーカー プロセスが開始するまで待機する必要があります。すべてのプールを 32 ビット モードで実行することで、これを軽減しました。
私の最大の問題はメモリ消費です。curl を使用してループ オーバーし、各クライアントで各アプリケーションをヒットすると、すべてのワーカー プロセスで約 100 MB の RAM が使用されます。つまり、安全に動作させるには 16 GB のサーバー RAM が必要です。アプリ自体がそれほど大きくなく、ひどく複雑でもないことを考えると、それはおかしな話です。各ワーカー プロセスのメモリの内訳は、おおよそ次のとおりです。プライベート バイト 70 MB、ワーキング セット 85 MB、WS 共有: 32 MB。これらはコストが RAM の使用量に直接関係するクラウド サーバーであるため、メモリは懸念事項です。コストがかからなかったとしても、メモリをそのように浪費するのを許すのは気が狂いそうです。
私の最初の質問は、IIS または ASP.NET を構成して、各アプリケーション インスタンスを個別にコンパイルするのではなく、3 つのアプリが実際にはまったく同じコードであることを認識するためにできることはありますか? ? クライアント * アプリケーション * 2 つのサーバーを実行すると、720 個の「アプリケーション」がディスク上にコンパイルされます。
2 番目の質問は、ベスト プラクティスの 1 つです。私のセットアップは正しいですか (より適切な言葉がないため)。コードの簡素化とセキュリティのために、RAM の浪費に見合う価値があるでしょうか? このように個別のアプリケーションを使用せずに、web.config 継承とセッション/アプリケーション/フォーム認証の利点を実現する別の方法はありますか?
セットアップを変更してアプリケーションを 3 つだけにし、これらのアプリケーションをクライアント対応にするために必要なコードの変更を考えると、かなり気が遠くなるような気がします。
- 各 MVC ルートのルートに {client} を追加します (1 つのアプリは MVC ではないため、異なる場合があります)。
- {client} を使用して、ディスク上の別の場所に保存されている構成ファイルを検索してロードします。おそらくjson形式か何かで。
- リクエストごとに、{client} が変更されていないことを確認し、変更されている場合は、すべてのセッション変数とアプリケーション変数をクリアします。セキュリティ上の問題を防ぐために、ユーザーの認証を解除します。
私は、私の代わりに決心してくれる人を探しているわけではありませんが、以前に同様の問題に直面したことがある人がいれば、その話を聞いてくれるとうれしいです. または、私が完全に間違った方向に進んでおり、コードとセットアップを変更する必要があるというコンセンサスが得られるかもしれません。問題に関するあらゆる種類のフィードバックは有用であり、高く評価されると思います。