アズール・キャッシュのパフォーマンスが悪い

Question

データベース・コールをキャッシュに切り替えると、実際にパフォーマンスが低下しました。新しい遺物によると、CLRの時間と応答時間に大きな変化が見られました。ジャンプについての添付のグラフを参照してください（キャッシュは0時0分に導入されました）。 変更されたのは、Azure App Fabric Cacheの導入でした。私たちのキャッシュクライアントはシングルトンパターンを使用しているため、Webサービスのインスタンス用に1つしかありません。キャッシュファクトリは一度作成された後で保存されるため、毎回接続を開くオーバーヘッドを解消することはできません。

さらに、NewRelicは、キャッシュが平均15ミリ秒に取っていることを報告します。多くの場合、15msはデータベースよりも遅くなることがあります。私たちは、私は2つのバイト配列のconstitsをキャッシュ付着しているオブジェクトNTO

、1は、およそ421の長さを有し、他は本当に、なぜ私たちが増え参照キャッシュの導入と理解していない8.

の長さを有し反応時間。バイト配列がキャッシュを使いませんか？

私のクラスは、この（前クラスに押し込まれることに読み込まれます2つのプロパティのみが他の2つのバイト配列のすべてであるデフォルト値に残っている）

[Table] 
public class GameState 
{ 
    [Column(IsPrimaryKey = true, IsDbGenerated = true, AutoSync = AutoSync.OnInsert)] 
    public int Id { get; set; } 

    [Column(UpdateCheck = UpdateCheck.Never, Name = "game_id")] 
    public int GameId { get; set; } 

    [Column(UpdateCheck = UpdateCheck.Never, Name = "player_id")] 
    public int PlayerId { get; set; } 

    [Column(UpdateCheck = UpdateCheck.Never, DbType = "VarBinary(max)")] //has a length around 421 
    public byte[] State { get; set; } 

    [Column(UpdateCheck = UpdateCheck.Never, IsDbGenerated = true, AutoSync = AutoSync.OnInsert)] 
    public DateTime Created { get; set; } 

    [Column(UpdateCheck = UpdateCheck.Never, Name = "update", IsDbGenerated = true, DbType = "timestamp")] //has a length of 8 
    public byte[] TimeStamp { get; set; } 
} 

おかげ

UPDATEのように見えます

私たちはいくつかのマイクロソフトのエンジニアと話をしましたが、なぜそれが遅いのかについて私たちに助けを与えることはできませんでした。あるエンジニアは、キャッシュ層がSQL Azureの上に構築されており、要求時間が長いことを説明しました。もう1人のエンジニアは、その主張を否定しましたが、共有キャッシングがどのように実装されたかは正確には分かりませんでした

AzureからAmazon EC2に切り替えることは決してできませんでした。比較可能なハードウェア上のAmazon EC2上では、応答時間は約60-70msに低下しました。

これを考慮する他の人にとって、これは私たちがスイッチで学んだことでした。

SQL Azureは共有DBホスティングです。あなたは他のDBをたくさん持っているあなた自身のDBをサーバに持っておらず、まともなトラフィックがあれば、あなたは抑えられるでしょう。彼らは成功談を購入しているチケットについて話し続けてきましたが、そのシナリオでは取引を処理する750のDBがありました。シャーディングは楽しいことではなく、より良い成功例は、あなたが1DBでこれらの要求をすべて処理したことです。

私たちはSSLを使用しており、IISでSSLを管理することで実際にCPUが強制終了されます。 AmazonはあなたのELBにsslを実行させ、その後IISボックスを使う必要はありません。これにより、要求をより迅速に処理するためにIISボックスが解放されました。

Amazonではmemcacheを実行できます。 Memcacheは素晴らしいです。軽量化された高速キャッシュ層（4GB以上の成長が可能）を持つことで、DBからの負荷が大きくなりました。

私たちは2012年1月にスイッチを元に戻しました。そのため、Azureは去年より良くなっていますが、もう一度チャンスを与える予定はありません。

Answer 1

Azureキャッシュのパフォーマンスは満足できません。基本的に、Azureキャッシュは通信時に独自の負荷分散を持つためです。しかし、ローカルキャッシュ機能を有効にしようとすると、負荷のパフォーマンスが向上します。

• 取引
• 帯域幅
• 同時接続パフォーマンスのテストで

私は、同時接続数の制限は、MSDNから、責任があると思われる：

Answer 2

ネットワーククォータは3つのバリエーションがあります。

各キャッシュオファリングでは、同じキャッシュに同時に開くことのできる接続数に制限があります。Windows Azureキャッシュを使用するアプリケーションでは、キャッシュサービスへの接続の方法を理解する必要があります。各キャッシュのオファリングでは、同じキャッシュに対して同時に開くことのできる接続数に異なる制限があります。

出典： https://azure.microsoft.com/en-us/documentation/articles/cache-dotnet-how-to-use-service/

ことはあまり助けにならないならば、あなたは別の並行処理モデルを比較検討するかもしれません。 AppFabricは、楽観的および悲観的同時実行モデルをサポートしています。詳細はhttp://msdn.microsoft.com/en-us/library/ee790890.aspxを参照してください。