3

私はいくつかの記事を読みましたが、推奨されるのは azure の開発アプリ ファブリック キャッシュであり、他の記事ではユニバーサル プロバイダーを使用し、sql azure を使用してセッション状態を sql azure テーブルに保存すると述べています。そこにいる専門家は、どちらが優れているのか、そしてその理由を教えてください。「なぜ」が必要なので、推薦のために私のケースを提出します.Thanks

4

2 に答える 2

2

キャッシュには、トランザクション/時間、帯域幅/時間、および同時接続の数に特定の制限があります。トランザクションと帯域幅のしきい値は1クロック時間あたりであるため、これらの制限を超えないようにする必要があります。価格は線形ではないため、セッションの使用量を見積もり、必要なキャッシュよりも1つ大きいキャッシュを作成できますが、これは考慮する必要があることです。

ユニバーサルプロバイダーを介したSQLAzureには、このような制限はありません。キャッシュストレージの要件はわかりませんが、キャッシュが100 MB未満の場合は、月額5ドルのキャッシュと、キャッシュサービスの最低45ドルについて話していることになります。また、4 GBのキャッシュスペース全体が必要な場合は、5GBのSQLAzureキャッシュの方が大幅に安価になります。

とはいえ、キャッシュプロバイダーには特定の使用目標があります。たとえば、4GBのキャッシュは、1時間あたり最大1280万のトランザクション、または1秒あたり3,500を超えるトランザクションをサポートします。128MBのキャッシュプロバイダーでさえ、1秒あたり100トランザクションを超えています。

だから：私は2つの基本的な基準で決定を見ていきます：

  • コストが要因であり、キャッシュトランザクションレートとデータボリュームをSQL Azureで処理できると思われる場合は、SQL Azureが最善の策のようです（キャッシュサービスの最大4GBをはるかに超えるサイズに拡張できます）。SQL Azureに関する公開されたトランザクションレート情報はありませんが、パフォーマンスの低下が見られる前に、簡単なテストを実行して、1秒あたりにプッシュできるセッションヒット数を確認できます。
  • アプリが非常に高いトランザクションレートを要求する場合、キャッシュの公開されたトランザクションターゲットは、より良いソリューションとしてキャッシュを指します。注：おそらく、単一のインスタンスからキャッシュに対して1秒あたり3,500トランザクションのようなものを生成することはできません。これは、よりマルチインスタンスのシナリオです。

キャッシュの詳細については、こちらをご覧ください。

編集SQLと共有キャッシュの他に、既存のロールのメモリを使用するか（コストはかかりません）、デプロイメント内のキャッシュロールを使用して（ロールインスタンスのコストに関係なく）、独自の専用キャッシュを構成できるようになりました。これは、デプロイメントと同じ場所に配置されるため、最速のオプションです。また、memcachedプロトコルもサポートしています。詳細については、こちらをご覧ください。

于 2012-03-18T01:34:35.983 に答える