実行する必要がある3つのコアASP.NETアプリケーションがあります。ミラー化されたIIS 7.5構成を使用して2つのWindows Server 2008 R2サーバーを設定し、次にトラフィックを転送するロードバランサと、別のサーバーを状態サーバーに設定します。それはすべてセットアップと作業です（まだ生産中ではありません）。共有ASP.NETアプリケーションを使用したIISセットアップでのメモリオーバーヘッドの削減
私たちは約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つのクライアントがパフォーマンスに関して他の誰かに問題を引き起こすことはありません）。
短所：
- 大幅なメモリのオーバーヘッドは、（例えば/ CLIENT1/APP1、/ CLIENT1/APP2、/ CLIENT2/APP1各アプリケーション・インスタンスクライアント
- ごとに1つのアプリプールを持つがあります。 ..）はASP.NETで別々にコンパイルされます。
- アプリケーションプールのウォームアップ時間のオーバーヘッドがあります。 1つのクライアントがしばらくのうちにサーバーにアクセスしていない場合、最初のヒットはワーカープロセスの開始を待つ必要があります。 32ビットモードですべてのプールを実行することでこれを緩和しました。
私の最大の問題はメモリ消費です。 curlを使用して各クライアントで各アプリケーションにヒットした場合、すべてのワーカープロセスは約100 MBのRAMを使用しています。つまり、安全に動作させるには16GBのサーバーRAMが必要です。それは、アプリそのものが実際にはそれほど大きくない、あるいはひどく複雑ではないと考えているからです。各ワーカープロセスのメモリ内訳は、おおよそ次のとおりです。プライベートバイト70 MB、ワーキングセット85 MB、WS共有：32 MBコストはRAM使用量に直接関係するクラウドサーバなので、メモリが懸念されます。たとえそれがコストではなかったとしても、それはメモリがそれのように無駄になることを許すのはまだ難しいようです。
私の最初の質問は、IISまたはASP.NETで各アプリケーションインスタンスを個別にコンパイルしないようにすることですが、実際には3つのアプリケーションが完全に同じコードなので、起動時間が短縮されることがわかりますおそらくメモリ使用量ですか？私がクライアント*アプリケーション* 2台のサーバーを実行すると、それは720個の「アプリケーション」がディスク上にコンパイルされたものです。
2番目の質問はベストプラクティスの1つです。私のセッティングは正しいですか？コードのシンプルさとセキュリティのためにRAMの価値はそれにふさわしいですか？ウェブの利点を達成する別の方法がありますか？設定継承とセッション/アプリケーション/フォームauthこのように別々のアプリケーションを持たないで？
セットアップを変更してアプリケーションを3つだけにするために必要なコードの変更を考え、アプリケーションをクライアントに認識させることは、かなり困難であり、グロスです。検索する{クライアント}を使用し、負荷の設定ファイルは、ディスク上の他の場所に格納されている
- 。おそらく、jsonの形式または何かで。
- 各リクエストで{client}が変更されていないことを確認し、変更されている場合はすべてのセッション変数とアプリケーション変数をクリアします。セキュリティ問題を防ぐためにユーザーの認証を解除します。
私は私のために私の心を補うために誰を探していないんだけど、誰もが前に同様の問題に直面している場合、それらを聞いていいだろう。あるいは、私が間違ったトラックに乗っていて、コードと設定を変更する必要があるというコンセンサスがあるかもしれません。問題に関するフィードバックはどんなものでも役立つと思います。
アプリケーション全体をシングルインスタンスのマルチテナントアプリケーションとして書き換えない限り、簡単な答えはないと思います。次に、お客様とのビジネスおよび既存のサービスレベル契約にも対処する必要があります。一部の顧客は、セキュリティ上の懸念から、他の顧客と共有されているアプリケーションプールやデータベースが好きではありません。まず、サービスレベル契約を確認し、実際にそのように保つ必要があるかもしれません。 – airmanx86
ところで、実際には、共有コードやWebアプリケーション全体をアセンブリに署名し、msiファイルとしてパッケージ化し、サーバーのGACにインストールすることで、少しコンパイルするのが楽になるかもしれません。 – airmanx86
どういうわけか私は何年もそれをしてきたが、 "マルチテナント"という用語を知らなくても、これまでのところ私のキャリアの中でこれを作ってきた。今私は少なくともウェブの周りを検索する良い言葉を持っています。ありがとう！今私は何を探すべきかを知っているので、明らかに私はこの問題を抱えている唯一の人ではない。そこにはいくつかの慰めがあります。 – mroach