新しい ASP.NET アプリケーションを開始するとき、将来のある時点で拡張する必要があることを認識している場合、全体的なリファクタリングなしで将来の拡張性を可能にする最も重要な設計上の決定は何ですか?
4 に答える
これらは、大量にアクセスされる Web アプリケーションに対する内部 ASP.Net の Do と Don't Do です。
一般的なガイドライン
- セッションを使用しない - SessionState=Off
- ViewState を完全に無効にする - EnableViewState=False
- 複雑な ASP.Net UI コントロールは使用せず、基本に固執します (DataGrid と単純なリピーター)。
- 最速かつ最短のデータ アクセス メカニズムを使用する (フロント サイトの sqlreaders に固執する)
アプリケーション アーキテクチャ
- 抽象化レイヤーを使用してキャッシュ マネージャーを作成します。これにより、将来アプリケーションのスケーリングを開始するときに、単純な System.Web.Cache をより複雑な分散キャッシュ ソリューションに置き換えることができます。
- 将来の成長をサポートするために、抽象化レイヤーを備えた専用の I/O マネージャーを作成します (S3 の誰か?)
- オンとオフを切り替えることができるメイン パイプラインにタイミング トレースを組み込みます。これにより、ボトルネックが発生したときにそれを検出できます。
- バックグラウンド処理メカニズムを採用し、現在のページをレンダリングするために必要でないものは何でも移動して、それを噛み砕きます。
- さらに良いことに、アプリケーションから他のアプリケーションにイベントを発生させて、非同期作業を実行できるようにすることを検討してください。
- データベースのスケーラビリティを準備し、独自のレイヤーを配置して、後でデータベースを分割するか、マスター/スレーブ シナリオで複数の読み取りサーバーを使用するかを決定できるようにします。
何よりも、他人の成功と失敗から学び、前向きでいること。
私のトップ3の決定は
- データベースでのセッション状態の無効化または保存。
- セッション状態での保存をできるだけ少なくします。
- 優れた N 層アーキテクチャ。ビジネス ロジックを分離し、DLL に直接アクセスする代わりに Web サービスを使用することで、ビジネス レイヤーとプレゼンテーション レイヤーの両方を確実にスケールアウトできます。データベースは、必要に応じてクラスター化することもできますが、投げかけたものは何でも処理できる可能性があります。
データベース内のデータのパーティション分割も確認できます。
サイトをスケーリングする必要があるかどうかに関係なく、これを行っていますが、認めざるを得ません。
非常に多くの考慮事項があるので、その主題に関する本を書くことができます。実際、すばらしい本があり、それは無料です。;-)
Microsoftは、.NETアプリケーションのパフォーマンスとスケーラビリティの向上をPDF電子書籍としてリリースしました。
It is worth reading cover to cover, if you don't mind the droll writing style. Not only does it identify key performance scenarios, but also establishing benchmarks, measuring performance, and how to apply what you learn.
一時的/静的データに対するしっかりしたキャッシュ ポリシーがあることを確認してください。データベースの呼び出しは、特に物理サーバーが分離されている場合はコストがかかるため、積極的にキャッシングを行ってください。