2

Windows azure キューの場合、ストレージあたりのスケーラビリティ ターゲットは約 500 メッセージ/秒と想定されています ( http://msdn.microsoft.com/en-us/library/windowsazure/hh697709.aspx )。いくつかのメッセージをキューに書き込むだけの次の簡単なプログラムがあります。プログラムが完了するまでに 10 秒かかります (1 秒あたり 4 メッセージ)。仮想マシン内 (西ヨーロッパ) からプログラムを実行しており、ストレージ アカウントも西ヨーロッパにあります。ストレージの geo レプリケーションをセットアップしていません。私の接続文字列は、http プロトコルを使用するように設定されています。

       // http://blogs.msdn.com/b/windowsazurestorage/archive/2010/06/25/nagle-s-algorithm-is-not-friendly-towards-small-requests.aspx
        ServicePointManager.UseNagleAlgorithm = false;

        CloudStorageAccount storageAccount=CloudStorageAccount.Parse(ConfigurationManager.AppSettings["DataConnectionString"]);

        var cloudQueueClient = storageAccount.CreateCloudQueueClient();

        var queue = cloudQueueClient.GetQueueReference(Guid.NewGuid().ToString());

        queue.CreateIfNotExist();
        var w = new Stopwatch();
        w.Start();
        for (int i = 0; i < 50;i++ )
        {
            Console.WriteLine("nr {0}",i);
            queue.AddMessage(new CloudQueueMessage("hello "+i));    
        }

        w.Stop();
        Console.WriteLine("elapsed: {0}", w.ElapsedMilliseconds);
        queue.Delete();

どうすればパフォーマンスを向上させることができますか？

編集：

Sandrino Di Mattia の回答に基づいて、最初に投稿したコードを再分析したところ、エラーを再現するには不十分であることがわかりました。実際、ServicePointManager.UseNagleAlgorithm = false; を呼び出す直前にキューを作成しました。私の問題を再現するコードは次のようになります。

        CloudStorageAccount storageAccount=CloudStorageAccount.Parse(ConfigurationManager.AppSettings["DataConnectionString"]);

        var cloudQueueClient = storageAccount.CreateCloudQueueClient();

        var queue = cloudQueueClient.GetQueueReference(Guid.NewGuid().ToString());

        //ServicePointManager.UseNagleAlgorithm = false; // If you change the nagle algorithm here, the performance will be okay.
        queue.CreateIfNotExist();
        ServicePointManager.UseNagleAlgorithm = false; // TOO LATE, the queue is already created without 'nagle'
        var w = new Stopwatch();
        w.Start();
        for (int i = 0; i < 50;i++ )
        {
            Console.WriteLine("nr {0}",i);
            queue.AddMessage(new CloudQueueMessage("hello "+i));    
        }

        w.Stop();
        Console.WriteLine("elapsed: {0}", w.ElapsedMilliseconds);
        queue.Delete();

app.config ファイルを使用して ServicePointManager を構成する Sandrino から提案されたソリューションには、アプリケーションの起動時に ServicePointManager が初期化されるという利点があるため、時間の依存性について心配する必要はありません。

4

2 に答える 2

10

数日前に同様の質問に答えました: How toachive more 10 inserts per second with azure storage tables .

テーブル ストレージに 1000 個のアイテムを追加するのに 3 分以上かかりましたが、回答で説明した変更により、4 秒 (250 リクエスト/秒) に短縮されました。結局のところ、テーブル ストレージとストレージ キューはそれほど違いはありません。バックエンドは同じで、データは単に別の方法で保存されます。また、テーブル ストレージとキューの両方が REST API を介して公開されるため、リクエストの処理方法を改善すると、パフォーマンスが向上します。

最も重要な変更点:

  • expect100Continue： 間違い
  • useNagleAlgorithm: false (すでにこれを行っています)
  • と組み合わせた並列リクエストconnectionManagement/maxconnection
于 2012-10-16T13:44:12.323 に答える
1

また、サービス ポイントを作成する前に ServicePointManager.DefaultConnectionLimit を増やす必要があります。実際、サンドリーノの答えは同じことを言っていますが、構成を使用しています。

クラウドでもプロキシ検出をオフにします。プロキシ構成要素で自動検出します。初期化が遅くなります。

分散パーティション キーを選択します。

コンピューティングと顧客の近くにアカウントを配置します。

必要に応じてアカウントを追加できるように設計します。

Microsoft は、2012 年 7 月の時点で、キューとテーブルの SLA を 2,000 tps に設定しています。

私は Sandrino のリンクされた回答を読んでいませんでした。申し訳ありませんが、まさにこれに関する Build 2012 セッションを見ていました。

于 2013-02-22T20:21:39.670 に答える