Azureテーブルのストレージトランザクションの制限

Question

同じテーブル/ストレージアカウントに対して複数の仮想マシンを使用する場合、ATSに対するパフォーマンステストとその動作が少し変わっています。

パイプライン全体が非ブロッキング（待機/非同期）であり、並行および並列実行にTPLを使用しています。

まず最初に、この設定では、約1200個の挿入しか得られません。これは、4つのコア+ 800mbpsのL VMボックスで実行されています。

私は一意のPKと一意のRKを持つ100.000行を挿入しています。これは最終的な配布を活用する必要があります。

より決定的な振る舞いは次のとおりです。

1台のVMを実行すると、1秒あたり約1200個の挿入が発生します。 3つのVMを実行すると、1秒あたりの挿入回数が約730になります。

彼らのターゲットを指定しているブログ記事を読むのは、かなりユーモアです。 https://azure.microsoft.com/en-gb/blog/windows-azures-flat-network-storage-and-2012-scalability-targets/

単一表Partition-表パーティション は、同じパーティションキー値を持つテーブル内のエンティティのすべてをしており、通常のテーブルには、多くのパーティションを持っています。単一のテーブルのパーティションがあるため、スループット目標は：

秒注あたり2,000実体までは、これは単一のパーティションではなく、単一のテーブルのためです。したがって、良好なパーティショニングを持つテーブルは、上記の全体的なアカウントターゲットである最大20,000エンティティ/秒まで処理できます。

1秒あたり20kを利用できるようにするにはどうすればよいですか？VMごとに1,2kを超える実行はどのように可能ですか？

-

アップデート：私は今も、個々のノードのための3つのストレージアカウントを使用して試しても、性能/スロットリング動作を取得している

。私は論理的な理由を見つけることができません。

-

アップデート2：

私はさらに、コードを最適化してきたし、今私は約1550

実行することが可能だ - 更新3

を：

私は米国西部でも試しました。パフォーマンスは悪いです。約33％低い。

-

更新4：

IはXL機からコードを実行しようとしました。 4の代わりに8つのコアと2倍のメモリと帯域幅があり、パフォーマンスが2％向上しているので、この問題は私の側にはありません。

Answer 1

コンピューティングインスタンスとストレージアカウントは同じアフィニティグループにありますか？アフィニティグループは、サービス間のネットワークの近接性が最適であることを保証し、ネットワークレベルでの待ち時間を短縮する必要があります。

アフィニティグループの設定は、[ネットワーク]タブで確認できます。

Answer 2

これはTCP Nagleと関係があると思われます。 this MSDN articleおよびthis blog postを参照してください。

本質的に、TCP Nagleは、小さな要求をバッチ処理するプロトコルレベルの最適化です。小さなリクエストをたくさん送信しているので、これはあなたのパフォーマンスに悪影響を及ぼす可能性があります。

あなたは、私は最大スループットが最適化された負荷のためであると考えている傾向があるでしょう、あなたのアプリケーション

ServicePointManager.UseNagleAlgorithm = false; 

Answer 3

を起動するときにこのコードを実行することにより、TCPのNagleを無効にすることができます。たとえば、今行っている個別のリクエストよりも、バッチリクエストを使用して高いパフォーマンスを達成できます。もちろん、PKにGUIDを使用している場合は、現在のテストでバッチ処理することはできません。

したがって、GUIDを使用していても100個のエンティティが同じPKを持つように、バッチインサートエンティティを100個（バッチごとに最大）のグループに挿入するようにテストを変更した場合はどうなりますか？

Answer 4

いくつかのコメント：

1. あなたは究極の 分布を得るためにユニークなPK/RKを使用していることを言及していますが、PKバランスが 即時ではないことを心に留めておく必要があります。最初にテーブルを作成すると、テーブル全体が の1つのパーティションサーバーによって処理されます。したがって、 いくつかの異なるPKを介して挿入を行っている場合、それらは1つのパーティション サーバーに移動し、単一の パーティションのスケーラビリティターゲットによってボトルネックになります。パーティションマスターは、 パーティションサーバーをホットサーバーとして識別した後で、複数のパーティションサーバー間でパーティションを分割し始めます。 < 2分テストでは、複数のパーティーサーバーまたはPKの の利点は表示されません。 の資料のスループットは、頻繁にアクセスされるデータ でよく分散されたPKスキームを対象にしており、データは複数のパーティションサーバー に分割されています。

2. あなたのVMのサイズは、CPU、メモリ、または帯域幅でブロックされていないため、問題はありません。小さなVMサイズから の完全なストレージパフォーマンスを達成できます。

3. チェックアウト http://research.microsoft.com/en-us/downloads/5c8189b9-53aa-4d6a-a086-013d927e15a7/default.aspxを参照してください。 私はちょうど私のストレージアカウントと同じデータセンター のWebRole VMからそのツールを使って簡単なテストを行いました。単一のVMのツールの インスタンスから、1秒あたり〜2800アイテムのアップロード 〜毎秒7300件のアイテムがダウンロードされます。これは1024バイトの エンティティ、10スレッド、100バッチサイズを使用しています。私は、このツールがどれほど効率的か、バグサイズ1を使って大きな結果（私は〜1000 /秒）を得ることができなかったのでNaglesアルゴリズムを無効にしても、少なくとも100バッチサイズではあなたは高いアイテム/秒を達成することができます。これは米国西部で行われた。

4. ストレージクライアントライブラリ1.7（Microsoft.Azure.StorageClient.dll）または2.0（Microsoft.Azure.Storage.dll）を使用していますか？ 2.0ライブラリにはいくつかのパフォーマンスが向上し、より良い結果が得られるはずです。