多くの同時ユーザーがいる.netポータルに取り組んでいます。そのため、スケーラビリティとパフォーマンスは、設計とアーキテクチャで対処する必要があります。アプリケーションで負荷分散を使用する予定です。
これを念頭に置いて、IIS Web サーバー (aspx、aspx.cs ファイルをホスト) とアプリケーション サーバー (ビジネス ロジックやデータ アクセス レイヤーなどの .net アセンブリをホスト) の間で通信する最良の方法は何でしょうか? .net リモーティングまたは SOAP Web サービスである必要がありますか?または他のアプローチはありますか?
ありがとう。
別のアプローチはありますか？ はい - オブジェクトを配布しないでください。最もスケーラブルなアプローチは、オブジェクトを互いに分散させないことです。あるフレーバーのコードを「アプリ サーバー」にデプロイし、別のフレーバーのコードを「Web サーバー」にデプロイする理由を自問してみてください。これらの 2 つのレイヤー間で行われる通信は、分散されている場合、市内通話よりもはるかに (など) コストがかかります。
今日の 64 ビット サーバー、そのすべてのメモリ、ホットな CPU、および ASP.NET の優れたメモリ管理を使用して、ビジネス ロジックと DAL を ASPX ファイルと同じ物理マシンに配置してみませんか? なぜだめですか？
スケーリングが必要な場合は、サーバーを追加します。単純。
もちろん、配布するのには十分な理由があります。最も一般的な正当な理由は、所有権のドメインに関係しています。複数の軸に沿って、セキュリティ管理、さらには予算と管理にさえ関係しています。つまり、後者の場合、チームがビジネス ロジックの実行を担当し、別のチームが Web レイヤーの構築と実行を担当している場合、管理の独立性を確保するために、これら 2 つのことを分散させることが理にかなっている可能性があります。コンピュータ コードを配布する正当な理由のほとんどは、コードを使用または開発する人間の組織の構造に由来しています。
データベース アクセス レイヤーと同じ CLR VM とメモリ ヒープを共有する同じ CPU で Web ページを実行してはならない技術的な理由はありません。
ディストリビューションで何をするかに関係なく、レイヤー間の接続を定義する形式的ではないインターフェイスでシステムを構築することは賢明ではありません。正式なインターフェイスを維持する場合、分散型アプローチと同じ場所に配置されたアプローチのパフォーマンスと効率を測定することは問題ありません。
アプリサーバーは本当に必要ですか? あなたは正確にどれくらい大きく話しているのですか？たとえば、Stackoverflow.com には 1 日に最大 50,000 のユニークなユーザーがいて、アプリ サーバーがありません。ほとんどのパフォーマンスのボトルネックはデータベースの問題に帰着するので、私はそれに集中します。
パフォーマンスに関するパターンとプラクティス グループのガイドライン、より具体的には、ガイドラインの第 6 章 - ASP.NET パフォーマンスの向上を参照することをお勧めします。可能であれば、アプリケーション層と UI 層を物理的に分割しないことを真剣に検討する必要があるという Cheeso に同意します。P&P ガイドラインには、次の注意事項があります。
不要なプロセス ホップを回避する
プロセス ホップはマシン ホップほど高価ではありませんが、可能な場合はプロセス ホップを避ける必要があります。プロセス ホップは、プロセス間通信 (IPC) とマーシャリングを必要とするため、追加のオーバーヘッドを引き起こします。たとえば、ソリューションで Enterprise Services を使用する場合、Enterprise Services アプリケーションをリモートの中間層に配置する必要がない限り、可能であればライブラリ アプリケーションを使用します。
リモート中間層のパフォーマンスへの影響を理解する
可能であれば、プロセス間およびコンピューター間通信のオーバーヘッドを回避します。ビジネス要件でリモート中間層を使用する必要がある場合を除き、プレゼンテーション、ビジネス、およびデータ アクセス ロジックは Web サーバー上に保持してください。ビジネスおよびデータ アクセス アセンブリをアプリケーションの Bin ディレクトリに配置します。ただし、次のいずれかの理由でリモート中間層が必要になる場合があります。
- インターネットに接続する Web アプリケーションと他の社内エンタープライズ アプリケーションとの間でビジネス ロジックを共有したいと考えています。
- スケールアウトとフォールト トレランスの要件により、中間層クラスターまたは負荷分散サーバーの使用が決定されます。
- 企業のセキュリティ ポリシーでは、Web サーバーにビジネス ロジックを配置することはできません。
とにかくアプリケーション ロジックを分割する必要がある場合は、WCF をトランスポート メカニズムとして使用できます。パフォーマンスに関しては、リモート処理に対してどのように積み重なるかわかりません。ただし、これはマイクロソフトが推進しているガイドラインであることを覚えているようです。
Clemens Vasters (Microsoft .NET Service Bus のテクニカル リーダー) は、MSDN フォーラムのこの回答で WCF とリモート処理について語っています。
非同期で書くことを学ぶ。
たとえば、CCRランタイムを調べます。
IO応答の待機をブロックされている各スレッドは、システムで使用できるスレッドが1つ少なくなります。
「理想的なロギング」をオフにして、管理コンソールを介してオンに戻す機能を残します。しかし、ロギングはしばしば隠れたボトルネックです。
CACHE CACHE CACHE！
最初にデータを取得するのに費用がかかった場合は、2回目にはお金を払わないでください。
ASP.netのセッション状態を回避する-これは深刻な肥大化を引き起こし、ページの応答性を大幅に低下させる可能性があります。
httpヘッダーを変更して、短いブラウザーキャッシュ（5秒から20秒）を指定します（コンテンツの性質によって異なります）
あなたがそれにいる間、GZIPを利用してください！
そしてたくさんのRAMを使う
これが私のヒントです
1）すべての静的ファイル（画像、css、js）をnginxなどのロードバランサーに移動します。これにより、IISサーバーの負荷が大幅に軽減され、メインの要求を処理するのに十分な空きリソースが確保されます。
2）キャッシュとデータベースアクセスの完全な回避について考えてください。
3）RESTの原則を可能な限り実装してみてください。
4）セッション状態を最小限に抑えます-可能であれば、それを完全に避けます。
Omar Al Zabirのこれらの記事には、いくつかの優れたパフォーマンスとスケーラビリティのポイントがあります。
10 ASP.NETのパフォーマンスとスケーラビリティの秘密
と
99.99％の利用可能なASP.NETおよびSQL Server SaaSプロダクションアーキテクチャ
（彼の著書「 ASP.NET3.5を使用したWeb 2.0ポータルの構築」も参照してください）