7

ATS に対してパフォーマンス テストを実行していますが、同じテーブル/ストレージ アカウントに対して複数の仮想マシンを使用すると、動作が少し奇妙になります。

パイプライン全体がノンブロッキング (await/async) であり、同時実行と並列実行に TPL を使用します。

まず第一に、このセットアップで約 1200 の挿入しか得られないのは非常に奇妙です。これは、4 コア + 800 mbps の 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/

単一テーブル パーティション - テーブル パーティションは、同じパーティション キー値を持つテーブル内のすべてのエンティティであり、通常、テーブルには多くのパーティションがあります。1 つのテーブル パーティションのスループット ターゲットは次のとおりです。

毎秒最大 2,000 エンティティ

これは単一のテーブルではなく、単一のパーティション用であることに注意してください。したがって、適切なパーティショニングを備えたテーブルは、上記の全体的なアカウント ターゲットである 20,000 エンティティ/秒まで処理できます。

1 秒あたり 20k を利用できるようにするにはどうすればよいですか? また、VM あたり 1.2k を超える実行を可能にする方法は?

--

アップデート：

また、個々のノードごとに 3 つのストレージ アカウントを使用してみましたが、まだパフォーマンス/スロットリング動作が発生しています。論理的な理由が見つかりません。

--

更新 2:

コードをさらに最適化した結果、約 1550 回実行できるようになりました。

--

更新 3:

私は今、米国西部でも試しました。そこではパフォーマンスが悪化します。約33%減。

--

更新 4:

XL マシンからコードを実行してみました。これは 4 コアではなく 8 コアであり、メモリと帯域幅が 2 倍になり、パフォーマンスが 2% 向上したため、明らかにこの問題は私の側ではありません..

4

4 に答える 4

4

いくつかのコメント:

  1. 独自の PK/RK を使用して最終的な配布を行っているとおっしゃっていますが、PK のバランスは即時ではないことに注意する必要があります。最初にテーブルを作成すると、テーブル全体が 1 つのパーティション サーバーによって処理されます。そのため、いくつかの異なる PK にまたがって挿入を行っている場合でも、それらは 1 つのパーティション サーバーに移動し、単一のパーティションのスケーラビリティ ターゲットによってボトルネックになります。パーティション マスターは、ホット パーティション サーバーを特定した後にのみ、複数のパーティション サーバー間でパーティションの分割を開始します。2 分未満のテストでは、複数のパーティション サーバーまたは PK の利点は見られません。この記事のスループットは、頻繁にアクセスされるデータを含む十分に分散された PK スキームを対象としており、データが複数のパーティション サーバー間で分割されます。

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

  3. Check out http://research.microsoft.com/en-us/downloads/5c8189b9-53aa-4d6a-a086-013d927e15a7/default.aspx. I just now did a quick test using that tool from a WebRole VM in the same datacenter as my storage account and I acheived, from a single instance of the tool on a single VM, ~2800 items per second upload and ~7300 items per second download. This is using 1024 byte entities, 10 threads, and 100 batch size. I don't know how efficient this tool is or if it disables Nagles Algorithm as I was unable to get great results (I got ~1000/second) using a batch size of 1, but at least with the 100 batch size it shows that you can achieve high items/second. This was done in US West.

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

于 2013-02-01T21:54:51.017 に答える
0

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

アフィニティグループの構成は、[ネットワーク]タブにあります。

于 2013-01-24T12:22:09.233 に答える
0

私は、最大スループットは最適化された負荷に対するものだと考える傾向があります。たとえば、現在行っている個別のリクエストよりも、バッチ リクエストを使用すると、より高いパフォーマンスを達成できるはずです。もちろん、PK に GUID を使用する場合、現在のテストでバッチ処理を行うことはできません。

では、テストを 100 個のグループ (バッチごとの最大数) でエンティティをバッチ挿入するように変更し、引き続き GUID を使用するが、どの 100 個のエンティティが同じ PK を持つか?

于 2013-01-25T12:57:08.233 に答える
0

これは TCP Nagle に関係していると思われます。この MSDN 記事とこのブログ投稿を参照してください。

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

アプリケーションの起動時にこのコードを実行することで、TCP Nagle を無効にすることができます。

ServicePointManager.UseNagleAlgorithm = false;
于 2013-01-24T21:23:59.953 に答える