ピーク負荷の下でASP.NETのパフォーマンスを向上させる4つの方法

概要

ASP.NETは、Webアプリケーションの開発で非常に人気があり、これらのアプリケーションの多くは、本質的にトラフィックが多く、何百万ものユーザーにサービスを提供しています。結果として、これらのアプリケーションはビジネスに大きな影響を与えるため、非常に重要です。

興味深いことに、ASP.NETアプリケーションアーキテクチャは、アプリケーション層で非常にスケーラブルです。また、HTTPプロトコルもステートレスです。これらは両方とも、各HTTP要求が最も適切なWebサーバーにルーティングされる負荷分散されたWebファームでASP.NETアプリケーションを実行できることを意味します。これにより、ユーザートラフィックの増加に応じて、WebファームにWebサーバーを簡単に追加できます。そして、これにより、ASP.NETアプリケーション層が非常にスケーラブルになります。しかし、ここでのスケーラビリティとはどういう意味ですか？

スケーラビリティとは、本質的に、ピーク負荷の下でも高性能を提供する能力です。したがって、ASP.NETアプリケーションページの応答時間が10ユーザーで非常に速く、100,000ユーザーで同じくらい速い場合、ASP.NETアプリケーションはスケーラブルです。ただし、ユーザー数を増やすとASP.NETの応答時間が遅くなる場合、アプリケーションはスケーラブルではありません。

問題：スケーラビリティのボトルネック

アプリケーション層のアーキテクチャは非常にスケーラブルですが、今日のASP.NETアプリケーションはスケーラビリティの大きなボトルネックに直面しています。これらのボトルネックは、次のXNUMXつの異なる領域で発生しています。

アプリケーションデータベース
ASP.NETセッション状態ストレージ
ASP.NET View State
静的出力用のASP.NETページの実行

以下、それぞれについて詳しく説明します。

アプリケーションデータベース

SQL ServerやOracleなどのアプリケーションデータベースは、トランザクションの負荷が増えるとすぐにスケーラビリティのボトルネックになります。これは、より強力なデータベースサーバーを購入することでデータベース層をスケールアップできますが、データベース層にサーバーを追加してスケールアウトすることはできないためです。たとえば、アプリケーション層で10〜20台のサーバーが表示されることは非常に一般的ですが、データベース層で同じことを行うことはできません。

ASP.NETセッション状態ストレージ

さらに、ASP.NETセッション状態をどこかに保存する必要があります。また、Microsoftが提供するすぐに使用できるオプションは、InProc、StateServer、およびSqlServerです。残念ながら、XNUMXつのオプションすべてに、パフォーマンスとスケーラビリティの大きな問題があります。 InProcとStateServerは、スティッキーセッションを使用し、セッションが作成されたのと同じサーバーですべてのHTTP要求を送信するように強制します。スティッキーセッションを回避するためにStateServerをスタンドアロンサーバーとして構成すると、StateServerは単一障害点になり、そのパフォーマンスも大きな問題になります。また、SqlServerは、ASP.NETセッションをSQLServerデータベースにBLOBとして格納します。また、このアプローチには深刻なパフォーマンスとスケーラビリティの問題があります。

ASP.NET View State

ASP.NET View State エンコードされた隠し文字列（多くの場合、サイズが数百KB）であり、HTTP応答の一部としてユーザーのブラウザに送信されます。ブラウザはそれを何もせず、HTTPポストバックの場合はWebサーバーに返します。これにより、ASP.NETページの応答が遅くなり、Webサーバーのネットワークカードにかかる負担が大きくなり、さらに多くの帯域幅が消費されます。そして、ご存知のように、帯域幅は安くはありません。

静的出力用のASP.NETページの実行

最後に、ASP.NET framework ページ出力が前の要求から変更されていない場合でも、ユーザー要求に対してASP.NETページを実行します。これは、トランザクションの少ない環境では問題ない場合があります。ただし、すでにすべてのリソースを限界まで拡張しているトランザクションの多い環境では、この余分な実行は非常にコストがかかり、スケーラビリティのボトルネックになる可能性があります。

ことわざにあるように、「チェーンの強さは、その最も弱いリンクと同じくらい強い」だけです。したがって、ASP.NETアプリケーション環境のどこかにスケーラビリティのボトルネックがある限り、アプリケーション全体の速度が低下し、停止することさえあります。

そして、皮肉なことに、これは、最高レベルのビジネス活動を行っているときにピーク負荷の下で発生します。したがって、速度低下やダウンタイムの影響は、ビジネスにとってはるかにコストがかかります。

NoSQL Database 答えではない

NoSQL database 動きは、リレーショナルデータベースのスケーラビリティの問題の結果として始まりました。 NoSQL database データを複数のサーバーに分割し、アプリケーション層と同じようにスケールアウトできるようにします。

しかし、 NoSQL database リレーショナルデータベースを放棄し、データを NoSQL database。そして、これは多くの理由で言うよりも簡単であり、実際には多くの場合不可能です。

NoSQL database■リレーショナルデータベースと同じデータ管理および検索機能がなく、リレーショナルとはまったく異なる方法でデータを保存する必要があります。さらに、リレーショナルデータベースを取り巻くエコシステムは、ほとんどの企業にとって放棄するには強すぎます。

結果として、 NoSQL databasesは、非構造化データを処理する場合にのみ役立ちます。また、ほとんどのASP.NETアプリケーションは、主に構造であり、リレーショナルデータベースに適したビジネスデータを処理しています。その結果、このデータをに移動することはできません NoSQL database 簡単に。

そして、最終的に使用する人でさえ NoSQL database 構造化されていないと見なすことができるデータ全体の小さなサブセットに対してこれを行います。そして、彼らは使用します NoSQL database 既存のリレーショナルデータベースと一緒に。

したがって、ほとんどの場合、リレーショナルデータベースを使用して、スケーラビリティの問題に対する別の解決策を見つける必要があります。幸いなことに、非常に実行可能な解決策があり、それについては以下で説明します。

解決策：インメモリ分散キャッシュ

上記のすべての問題の解決策は、次のようなアプリケーション展開でインメモリ分散キャッシュを使用することです。 NCache. NCache ありますオープンソース分散キャッシュ非常に高速で線形にスケーラブルな.NET用。これも配布されるメモリ内オブジェクトストアと考えてください。インメモリであると非常に高速になり、分散されると線形にスケーラブルになります。

インメモリ分散キャッシュの良いところは NCache つまり、既存のリレーショナルデータベースの使用を停止するように求められることはありません。キャッシュはリレーショナルデータベースのスケーラビリティのボトルネックをすべて取り除くため、リレーショナルデータベースの上でキャッシュを使用できます。

では、インメモリ分散キャッシュはどのようになっていますか NCache リレーショナルデータベースよりもスケーラブルですか？上手、 NCache キャッシュサーバーのクラスターを形成し、これらすべてのサーバーからのCPU、メモリ、およびその他のリソースを一緒にプールします。

と、 NCache キャッシュまたはアプリケーションを停止することなく、実行時にキャッシュサーバーを追加できます。また、これにより、アプリケーションを線形にスケーリングし、極端なトランザクション負荷を処理できます。これは、リレーショナルデータベースでは実行できないことです。

のようなインメモリ分散キャッシュ NCache 実行時にキャッシュサーバーをキャッシュクラスター（キャッシング層）に追加できるようにすることで、線形にスケーリングします。しかし、次のようなソリューションからどのような種類のパフォーマンス数値を期待する必要がありますか NCache.

以下の通りです NCache パフォーマンスの数値。あなたは完全に見ることができます NCache パフォーマンスベンチマークページをご覧ください

ご覧のとおり、インメモリ分散キャッシュは次のようになります。 NCache 読み取りと書き込みにミリ秒未満のパフォーマンスを提供し、キャッシュサーバーを追加するだけでトランザクション容量を直線的に拡張できます。

インメモリ分散キャッシュがどのようになっているのか見てみましょう NCache 上記のさまざまなスケーラビリティのボトルネックを解決します。

アプリケーションデータのキャッシュ

アプリケーションデータキャッシュを使用すると、データベースのボトルネックを取り除くことができます。のようなインメモリ分散キャッシュ NCache アプリケーションデータをキャッシュし、これらの高価なデータベーストリップを減らすことができます。データベーストラフィックの70〜90％をインメモリ分散キャッシュに転送することが期待できます。これにより、データベースへの負荷が軽減され、データベースのパフォーマンスが向上し、速度を落とすことなく、より大きなトランザクション負荷を処理できるようになります。

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;
}

図4：アプリのデータキャッシュにインメモリ分散キャッシュを使用する

アプリケーションデータのキャッシュとは、リレーショナルデータベースから取得したアプリケーションデータをキャッシュすることを意味します。これは通常、ドメインオブジェクト（エンティティとも呼ばれます）の形式です。これは、次のような分散キャッシュの使用方法の例です。 NCache アプリケーションデータキャッシング用。

ASP.NETセッション状態のキャッシュ

のようなインメモリ分散キャッシュ NCache ASP.NETセッション状態を保存するのにも最適な場所です。上記のXNUMXつのオプション（InProc、StateServer、およびSqlServer）よりもはるかに高速でスケーラブルです。 NCache メモリ内にあり、ASP.NETセッション状態である「オブジェクト」である値を持つキーと値のインターフェイスを提供するため、より高速です。また、分散キャッシュであるため、スケーラブルです。

と、 NCache また、豊富なキャッシュトポロジを介してセッションをインテリジェントに複製するため、キャッシュサーバーがダウンしても、セッションデータが失われることはありません。この複製が必要な理由は NCache インメモリストアを提供し、メモリはストレージに違反しています。

NCache また、アウトプロセスで保存する前に必要なASP.NETセッション状態オブジェクトのシリアル化を高速化します。 NCache これは、通常の.NETシリアル化よりも10倍高速な動的コンパクトシリアル化機能を使用して行われます。この機能は、コードを変更せずに使用できます。

プラグインできます NCache セッション状態プロバイダー以下に示すように、web.configファイルにいくつかの変更を加えて、ASP.NETアプリケーションに（SSP）モジュールを追加します。

<system.web>
 ...
 <assemblies>
<add assembly="Alachisoft.NCache.SessionStoreProvider, Version=4.3.0.0,
 Culture=neutral, PublicKeyToken=CFF5926ED6A53769" />
 </assemblies>
 <sessionState cookieless="false" regenerateExpiredSessionId="true"
 mode="Custom" customProvider="NCacheSessionProvider"
timeout="20">
<providers>
 <add name="NCacheSessionProvider"
 type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider"
 useInProc="false" cacheName="myDistributedCache"
 enableLogs="false“ writeExceptionsToEventLog="false” />
</providers>
 </sessionState>
 ...
</system.web>

図5：プラグイン NCache Web.ConfigのASP.NETセッション状態プロバイダー（SSP）として

ASP.NET View State キャッシング

方法についてはすでに説明しました ASP.NET View State は、Webサーバーからユーザーのブラウザに送信されるエンコードされた文字列であり、HTTPポストバックの場合はWebサーバーに返されます。しかし、InMemoryDistributedCacheの助けを借りて NCache、これをキャッシュできます ASP.NET View State サーバー上で、その代わりに小さな一意のIDのみを送信します。

NCache を実装しました ASP.NET View State キャッシングモジュールカスタムASP.NETページアダプターおよびASP.NETPageStatePersisterを介して。こちらです、 NCache HTTPリクエストとレスポンスの両方をインターセプトします。応答時に、 NCache エンコードされた文字列の「値」部分を削除してキャッシュし、代わりにこの「値」に一意の識別子（キャッシュキー）を配置します。

次に、次のHTTPリクエストが来ると、それを再度インターセプトし、一意の識別子を、以前にキャッシュに入れた実際のエンコードされた文字列に置き換えます。このように、ASP.NETページは何も違いに気付かず、以前と同じようにビューステートを含むエンコードされた文字列を使用します。

以下の例は、 ASP.NET View State キャッシュなしでエンコードされた文字列と、キャッシュが組み込まれている場合に何が起こるか。

//ASP.NET View State without Caching
<input id="__VIEWSTATE"
 	type="hidden"
 	name="__VIEWSTATE"
 	value="/wEPDwUJNzg0MDMxMDA1D2QWAmYPZBYCZg9kFgQCAQ9kFgICBQ9kFgJmD2QWAgIBD
		xYCHhNQcm2aW91c0NvbnRyb2xNb2RlCymIAU1pY3Jvc29mdC5TaGFyZVBvaW50Lld
		lYkNvbnRyb2xzLlNQQ29udHJbE1vZDA1XzRlMjJfODM3Y19kOWQ1ZTc2YmY1M2IPD
		xYCHhNQcm2aW91c0NvbnRyb2xNb2RlCymIAU1pY3Jvc29mdC5TaGFyZVBvaW50Lld
		lYkNvbnRyb2xzLlNQQ29udHJbE1vZDA1XzRlMjJfODM3Y19kOWQ1ZTc2YmY1M2IPD
		... ==" />
			
//ASP.NET View State with Caching
<input id="__VIEWSTATE"
	type="hidden"
	name="__VIEWSTATE"
	value="vs:cf8c8d3927ad4c1a84da7f891bb89185" />

図6： ASP.NET View State キャッシュの有無にかかわらずエンコードされた文字列

静的ページ出力用のASP.NET出力キャッシュ

ASP.NETは、ページ出力が変更されていない場合でも過剰なページ実行の問題に対処するためのASP.NET出力キャッシュフレームワークを提供します。このフレームワークを使用すると、ページ全体またはページの一部の出力をキャッシュできるため、次にこのページが呼び出されたときに実行されず、代わりにキャッシュされた出力が表示されます。すでにキャッシュされた出力を表示することは、ページ全体を再度実行するよりもはるかに高速です。

<caching>
   <outputCache defaultProvider ="NOutputCacheProvider">
     <providers>
       <add name="NOutputCacheProvider"
         type="Alachisoft.NCache.OutputCacheProvider.NOutputCacheProvider,
               Alachisoft.NCache.OutputCacheProvider, Version=x.x.x.x,
               Culture=neutral, PublicKeyToken=1448e8d1123e9096"
				  
               cacheName="myDistributedCache" exceptionsEnabled="false"
               writeExceptionsToEventLog="false" enableLogs="true” />"
     </providers>
   </outputCache>
</caching>

図7：ASP.NET出力キャッシュプロバイダーのセットアップ NCache Web.Config で

NCache .NET4.0以降のバージョン用のASP.NET出力キャッシュプロバイダーを実装しました。これにより、プラグインできます NCache シームレスに、プログラミングの労力なしで。の場合には NCache、このプロバイダーは、複数のサーバーにまたがるインメモリ分散キャッシュ用です。したがって、ASP.NETアプリケーションが負荷分散されたWebファームで実行されている場合、サーバー1からキャッシュされたページ出力は、Webファーム内の他のすべてのサーバーですぐに利用できます。以下はプラグインの方法です NCache ASP.NET出力キャッシュプロバイダーとして。

分散キャッシュアーキテクチャ

トラフィックの多いASP.NETアプリケーションは、特にピーク時にダウンする余裕がありません。これらのタイプのアプリケーションの場合、優れたインメモリ分散キャッシュのようなXNUMXつの重要なアーキテクチャ上の目標があります。 NCache 提供します。彼らです：

高可用性
線形スケーラビリティ
データの複製と信頼性

以下に各エリアについて説明します。

高可用性

の最も重要なアーキテクチャの目標のXNUMXつ NCache 高可用性とキャッシュの弾力性を実現することです。そして、それは次のアーキテクチャ機能を通じてそれを行います。

自己回復型のピアツーピアキャッシュクラスター： NCache TCP/IPを介してキャッシュサーバーのクラスターを構築します。このクラスターにはピアツーピアマスター/スレーブノードがなく、多数決クラスタリングがないことを意味するアーキテクチャ。代わりに、各ノードは同等のピアです。これにより、 NCache ノードがダウンする可能性があり、クラスターが自動的に調整して実行を継続し、アプリケーションが中断されない状況を処理するため。
動的構成： これは、構成ファイルにハードコーディングする必要がないことを意味します。それの訳は NCache 実行時に多くの構成情報をキャッシュクライアント（アプリケーションを意味する）に伝達します。したがって、実行時にキャッシュサーバーを追加すると、クラスターメンバーシップが自動的に更新され、クラスターはすべてのキャッシュクライアントにこの変更について通知します。同じ方法で処理される他の構成変更のホストがあります。
接続フェイルオーバーのサポート： これは、キャッシュサーバーがダウンしたときに、キャッシュクラスターとキャッシュクライアントが中断することなく動作を継続できる機能です。キャッシュクラスターの場合、この状況に対処する自己回復品質についてはすでに説明しました。キャッシュクライアントの場合、これは、キャッシュクライアントがクラスター内の他のキャッシュサーバーと対話することによって機能し続けることを意味します。

線形スケーラビリティを備えたデータレプリケーション

インメモリ分散キャッシュのような NCache ストアとしてメモリを使用する場合、信頼性を確保するためにデータレプリケーションを提供する必要があります。ただし、同時に、線形スケーラビリティを妥協することはできません。これは、次のような分散キャッシュを使用する最も重要な理由であるためです。 NCache.

ここでいくつか紹介します NCache キャッシングトポロジこれらの両方の目標を達成するのに役立ちます。

パーティション化されたキャッシュ： NCache キャッシュサーバーの数に基づいてキャッシュを分割し、各キャッシュサーバーにXNUMXつのパーティションを割り当てます。また、実行時にキャッシュサーバーを追加または削除するときに、パーティションの数を調整します。サーバーを追加すると、このキャッシングトポロジによって全体的なストレージサイズが増加し、CPUの処理能力も向上するため、パーティション分割は線形スケーラビリティを確保するための主要な方法です。
パーティション化されたレプリカキャッシュ： パーティショニングに加えて、 NCache また、各パーティションのレプリカも提供します。これらのレプリカは、パーティション自体とは異なるキャッシュサーバーに存在し、キャッシュサーバーがそのパーティションとともにダウンした場合に、レプリカがすぐに使用可能になるようにします。このようにして、データの信頼性が提供されます。各パーティションを別のキャッシュサーバーにXNUMX回だけ複製することにより、 NCache 線形スケーラビリティを損なうことなくデータの信頼性を実現します。
クライアントキャッシュ（キャッシュの近く）： のもう一つの非常に重要な機能 NCache クライアントキャッシュです。これは、キャッシュクライアントマシン（つまり、Webサーバーまたはアプリサーバー）に配置されるローカルキャッシュであり、InProc（アプリケーションプロセス内に存在することを意味します）にすることもできます。これは基本的にキャッシュの上にあるキャッシュであり、スケーラビリティの向上とともにパフォーマンスが大幅に向上します。 NCache キャッシング層へのトラフィックも減少するためです。

ご覧のとおり、Partitioned-Replica Cacheは、各キャッシュサーバーにXNUMXつのパーティションとXNUMXつのレプリカを配置します。また、信頼性を確保するために、レプリカが常に別のキャッシュサーバー上にあることを保証します。

まとめ

ASP.NETアプリケーションが今日直面している最も一般的なパフォーマンスとスケーラビリティのボトルネックを強調し、次のようなインメモリ分散キャッシュを使用してこれらを克服する方法を示しました。 NCache. NCache は、.NETおよびJavaアプリケーション用のオープンソース分散キャッシュです。そのため、制限なく使用できます。あなたはについてもっと知ることができます NCache 次のリンクで