ごく最近、MicrosoftはWindows Azureプラットフォーム用の大規模なサービスパックを発表しました。 革新のリストには、待望のWindows Azureキャッシングの更新が含まれていました。 以前は、開発者は分散キャッシュシステムで作業する際にいくつかの困難に直面していました-キャッシュの動作は非常に遅いです。 Windows Azureはキャッシュデータを別のサーバーに保存したため、データサンプルを要求するのに約
30〜100ミリ秒かかりました。これは、データアクセスを高速化するシステムでは許可されません。
それでは、キャッシングシステムの何が変わったのでしょうか？
マイクロソフトは、競合他社に追いつくことを決定し、インメモリキャッシュのサポートを追加しました。 現在、データは別のサーバーではなく、サーバーのRAMに保存されているため、データへのアクセスは即座に発生します。 例としてASP.NET MVC 3（C＃）を使用して、新しいキャッシュを実装し、古いキャッシュと作業速度を比較してみましょう。
キャッシングプロバイダー
キャッシュにアクセスするには、プロバイダーが必要です。 プロバイダーを実装するには、必要なメソッドを使用してプロバイダーのインターフェイスを作成します。
public interface ICacheProvider { void RemoveFromCache(string key); T GetFromMethod<T>(string cacheKey, TimeSpan cacheDuration, Func<T> method); T GetFromMethod<T>(string cacheKey, Func<T> method); }
最初の方法は、明らかに、キーによってキャッシュからオブジェクトを削除し、残りはキーと期間が設定されたデータを受け取ります（キャッシュがない場合は追加します）。
次のステップは、プロバイダー自体を実装することです。
Windows Azure SDK 1.7のインストールプロセスについては説明していません。開発者はWindows Azureでの開発に必要なすべてのライブラリとコンポーネントを持っていることが理解されますプロバイダーを実装する際に考慮すべきいくつかの重要な点に注意してください。
- キャッシュには完全なクリーニング機能がないため、更新をリリースするときに古いデータを無効にする可能性を考慮する必要があります。
- エラーを回避するために、キャッシュへの書き込みで生成できるスレッドは1つだけです。
- Windows Azureキャッシングは無料の機能ではないため、キャッシュアクセスを最小限に抑える必要があります。
プロバイダー自体は次のようになります。
public class AzureCacheProvider : ICacheProvider {
ここで
HttpContext.Current.Itemsは、データへのアクセスが繰り返される場合に、キャッシュからの現在の要求で既に受信したオブジェクトをメモリに格納するために使用されます。
ロール構成
プロバイダーを作成した後、キャッシュを構成する必要があります。 SDK 1.7では、ロールプロパティに新しい[キャッシュ]タブが追加されました。
このタブで、キャッシュサポートを有効にし（キャッシュを有効にする）、データに割り当てるメモリの量を設定します（例：Co-located Role：Cache Size 30％）
Web.config
最終的な準備は、Web.configに新しいセクションを追加することです。 ファイルの先頭に
configSectionsセクションがない場合、追加する必要があります。 次に、次のコードを内部に配置します。
<section name="dataCacheClients" type="Microsoft.ApplicationServer.Caching.DataCacheClientsSection, Microsoft.ApplicationServer.Caching.Core" allowLocation="true" allowDefinition="Everywhere"/>
Web.configの最後に、
dataCacheClientsセクションの説明を追加します。
<dataCacheClients> <tracing sinkType="DiagnosticSink" traceLevel="Error" /> <dataCacheClient name="default"> <autoDiscover isEnabled="true" identifier=" Web-, " /> </dataCacheClient> </dataCacheClients>
これで、Windows Azureキャッシングの構成が完了しました。 ヘルスチェックに移りましょう。
キャッシュテスト
キャッシュをテストするには、現在の時刻をキャッシュする簡単なページを作成します。
<h1>Cache test</h1> Before: <%=DateTime.Now.Millisecond%> ms<br/> <%=Facade.Instance.Cache.GetFromMethod("currentTime", () => DateTime.Now)%><br/> After: <%=DateTime.Now.Millisecond%> ms<br/> <%using(Html.BeginForm("ClearCache","Admin"))%> <%{%> <input type="submit" value="Clear Cache"/> <%}%>
上記のコードの
Facade.Instance.Cacheは、IoCを使用して取得した
AzureCacheProviderインスタンスです。
ClearCacheアクションは
ClearCacheにシンプルに見えます。
public ActionResult ClearCache() { Facade.Instance.Cache.RemoveFromCache("currentTime"); return View("admin"); }
結果
プロジェクトをコンパイルし、クラウドでページを起動すると、次の結果が表示されます。
Cache test
Before: 553 ms
6/10/2012 11:09:40 AM
After: 569 ms最初にページを開くと、キャッシュにエントリが追加されます。この例では約16ミリ秒かかります。 次回ページが更新されると、結果は次のようになります。
Cache test
Before: 508 ms
6/10/2012 11:09:40 AM
After: 508 ms新しいインメモリ分散キャッシュからデータを取得するのにかかる時間は1ミリ秒未満です。 速度面では、このキャッシュはInProcキャッシュに劣りません。
以前はどうでしたか？
以前の状態を確認するには、SDKをバージョン1.6にロールバックし、Web.configに小さな変更を加える必要があります。
dataCacheClientsセクションを次のように置き換えます。
<dataCacheClients> <dataCacheClient name="default"> <hosts> <host name="[ ID].cache.windows.net" cachePort="22233" /> </hosts> <securityProperties mode="Message"> <messageSecurity authorizationInfo="[ ]"></messageSecurity> </securityProperties> </dataCacheClient> </dataCacheClients>
プロジェクトをコンパイルしてテストページを開くと、次の結果が表示されます。
Cache test
Before: 521 ms
6/10/2012 11:09:40 AM
After: 550 msつまり キャッシュへのエントリの追加およびページの更新後の29ミリ秒：
Cache test
Before: 501 ms
6/10/2012 11:09:40 AM
After: 533 msキャッシュエントリの取得に32ミリ秒。
まとめ
MicrosoftがWindows Azureの主な問題の1つである分散キャッシュの問題を解決した最新のイノベーション。 これで、アプリケーションパフォーマンスの低下を恐れずに分散キャッシュを使用でき、Azureクラウド内でこれに他のツールを使用したユーザーは、Windows Azure APIが提供する機能に戻ることができます。