ASP.NET は、トラフィックの多い Web アプリケーションを開発する開発者にとって最も重要な選択肢になりました。 そのスケーラブルな性質により、ASP.NET アプリケーション層は、XNUMX 日あたり数百万の要求を持つ数千の同時ユーザーをシームレスに処理できます。 このような高トラフィックの ASP.NET アプリケーションは、ロード バランサーを使用して負荷分散された Web ファームに展開され、ユーザー要求を複数の Web サーバーにルーティングします。
ASP.NET アプリケーション層は、トランザクションの負荷が高い場合でも非常に優れたパフォーマンスを発揮しますが、アプリケーションは他の領域で重大なスケーラビリティのボトルネックに直面しています。 これらのボトルネックにより、ASP.NET アプリケーションの速度が低下する可能性があり、ビジネス アクティビティがピークに達したときにアプリケーションが停止することさえあります。
問題:XNUMXつのパフォーマンスのボトルネック
これら XNUMX つの ASP.NET パフォーマンスのボトルネックについて以下に説明します。
データベースのボトルネック
負荷分散された Web ファームでは、トランザクションの負荷が増加したときに、Web サーバーを簡単に追加して線形にスケーリングできます。 ただし、同じ方法でデータベース層 (SQL Server、Oracle、その他) にデータベース サーバーを追加することはできません。 そのため、データベースの速度が低下し始め、ある時点でクラッシュすることさえあります。 この内訳は、アプリケーションが直面する最も重大なパフォーマンスのボトルネックです。
ASP.NETセッション状態ストレージのボトルネック
ASP.NET セッション状態はどこかに保存する必要があり、その保存場所がアプリケーション データベースのようなボトルネックになります。 Microsoft が提供するストレージ オプションには、InProc、State Server、および SQL Server の XNUMX つがあります。 XNUMX つすべてにパフォーマンスのボトルネックがあります。
InProc では、Web サーバーごとに XNUMX つのワーカー プロセスを使用する必要があります。これは、複数のワーカー プロセスを持つことが推奨されるマルチプロセッサまたはマルチコア環境では機能しません。
また、負荷分散された Web ファームでは、他のサーバーがアイドル状態である間にこの Web サーバーが過負荷になっている場合でも、常にユーザー要求を Web サーバーに送信してセッションを作成するために、ロード バランサーにスティッキー セッション ビットが必要です。
また、SQL Server は ASP.NET セッション状態を BLOB として格納するため、ASP.NET セッション状態の理想的なストアではありません。
NCache 詳細 ASP.NETセッションキャッシング ASP.NETセッションキャッシングドキュメント
ASP.NET View State ボトルネック
ASP.NET View State ボタンやドロップダウンなどのコントロールのデータを保持するために、Web サーバー上に構築されたクライアント側の状態管理機能です。 このデータはブラウザに送信され、ポストバックが発生したときに返されます。 と ASP.NET View State 文字列のサイズは簡単に数百KBになり、毎日受け取る数百万のリクエストを掛けることができます。
これにより、ASP.NET アプリケーションの応答時間が遅くなるだけでなく、余分な帯域幅が大量に消費され、運用コストが大幅に増加する可能性があります。
不必要なページの実行
多くの場合、基になるデータが変更されていないため、ASP.NET ページの出力は複数の要求間で変更されません。 ただし、ページは引き続き実行され、前回と同じ出力が生成されます。 この余分なページの実行は、メモリや CPU などのシステム リソースを大量に消費し、データベース呼び出しも行います。
解決策:インメモリ分散キャッシュ
これらすべての問題に対する最も適切な解決策は、インメモリ分散キャッシュを ASP.NET に組み込み、 ASP.Net Core アプリケーション。 NCache .NET 用の一般的なオープン ソース分散キャッシュです。 XNUMX つのパフォーマンスのボトルネックを修正する方法について簡単に説明しましょう。 NCache.
NCache 詳細 ASP.NET Core セッションストレージ戦略 ASP.NET View State キャッシングのプロパティと概要
アプリケーションデータのキャッシュ
NCache では、アプリケーション データ (読み取り専用の参照データと頻繁に変更されるトランザクション データの両方) をキャッシュして、コストのかかるデータベースへの移動を減らすことができます。 データベースにアクセスする代わりに、 NCache リクエストの 85 ~ 90% をキャッシュにルーティングします。 これにより、データベースの競合の可能性が排除されます。
データベースとは異なり、 NCache ボトルネックになることはありません。 分散キャッシュ & 直線的にスケーリングする. NCache キャッシュ サーバーのクラスターを構築し、トランザクションの負荷が増加するにつれてクラスターにサーバーを追加できるようにします。 以下は、データベースからデータを取得し、キャッシュ クラスターに格納するサンプル コードです (まだキャッシュに存在しない場合)。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
Customer Load(string customerId) { // Key format: Customer:PK:1000 string key = "Customers:CustomerID:" + customerId; Customer cust = (Customer) _cache[key]; if (cust == null) { // Item not in cache so load from db LoadCustomerFromDb(cust); // Add item to cache for future reference _cache.Insert(key, cust); } return cust; } |
セッション状態のストレージ構成
NCache ASP.NET セッションをキャッシュに保存することもできます。 これは、他のストレージ オプションよりもはるかに高速なインメモリ ストアです。 信頼性を提供するために、 NCache 複数のサーバーでセッションを複製します。 そのため、サーバーがクラッシュしても、セッション データが失われることはありません。 NCache プログラミングの手間がかからず、web.config の変更によってシームレスにプラグインできるということです。 以下は例です。
1 2 3 4 5 6 7 8 9 |
<configuration> ... <sessionState cookieless="false" regenerateExpiredSessionId="true" mode="Custom" customProvider="NCacheSessionProvider" timeout="20"> <providers> <add name="NCacheSessionProvider" |
状態構成の表示
NCache キャッシュできます ASP.NET View State ブラウザに識別子キーのみを送信することにより、Webサーバー側で。 ポストバックで戻る間、 NCache HTTP ハンドラを介して識別子キーをインターセプトすることにより、ビューの結果を取得します。 このビュー ステートは ASP.NET ページに送信されます。
最終的な結果として、帯域幅のフットプリントがはるかに小さい、はるかに高速なASP.NETアプリケーションが実現します。 以下は、使用方法の構成変更の例です。 NCache キャッシング用 ASP.NET View State:
ASP.NET出力キャッシュ
出力が変更されない場合に ASP.NET ページが不必要に実行されるのを防ぐために、ASP.NET は 出力キャッシュ 単一サーバーおよび単一ワーカー プロセス構成のフレームワーク。 NCache一方、マルチサーバーおよびマルチワーカープロセス構成用に拡張します。
介して NCache、データベースで関連データが変更されると、ページの有効期限が切れる可能性もあります。 以下に例を示します。
まとめ
要するに、 NCache an インメモリ分散キャッシュ 線形のスケーラビリティ、シンプルなビュー ステート構成、およびアプリケーションとのシームレスな構成を備えたこのソリューションは、これらすべてのパフォーマンスのボトルネックに対する最適なソリューションです。 これらの機能は、 パフォーマンス .Net アプリケーションを高速化し、信頼性と可用性を高めます。