テーブルに挿入するメソッドを使用してワーカー ロールで WCF を実行しています。
このメソッドにアクセスしてテーブルにデータを挿入するクライアントがたくさんありますが、これには本当にパフォーマンスが必要です。
挿入メソッド内で 1 つずつ挿入を行うため、WCF が 100 レコードを受け取った後に一括挿入を行うように変更したいと考えています。後で一括挿入を行うために、このレコードのリストを含む変数を保存できる場所で、どうすればそれを行うことができますか?
テーブルに挿入するメソッドを使用してワーカー ロールで WCF を実行しています。
このメソッドにアクセスしてテーブルにデータを挿入するクライアントがたくさんありますが、これには本当にパフォーマンスが必要です。
挿入メソッド内で 1 つずつ挿入を行うため、WCF が 100 レコードを受け取った後に一括挿入を行うように変更したいと考えています。後で一括挿入を行うために、このレコードのリストを含む変数を保存できる場所で、どうすればそれを行うことができますか?
データの耐久性 (または耐久性の欠如) について考える必要があります。100 回のアップロードを待つ場合、データを一時的にどこに保存しますか? 唯一の安全な場所は、BLOB、テーブル、またはキュー (または SQL Database サービス) です。
RAM に保存すると揮発性であり、データが失われる可能性があります (さらに、データは複数のサーバー インスタンスに分割されるため、サーバー インスタンスの 1 つをフラッシュする前に、実際には 100 をはるかに超えるデータ項目をバッファリングすることになる可能性があります)。
キューに保存すると、テーブルへの書き込みと同じパフォーマンス曲線に到達します。ブロブと同じです。
これは時期尚早の最適化である可能性があります。Table Storage では、パーティションごとに 1 秒あたり 2,000 トランザクション (ストレージ アカウント全体で 1 秒あたり最大 20,000 トランザクション) が可能です。また、複数のストレージ アカウントを持つことができます。
データを慎重にパーティション分割すると (さまざまなパーティション キーを使用して、すべてを 1 つのパーティションに格納するのではなく)、ストレージ スループットで 1 秒あたり 2,000 をはるかに超えるトランザクションが表示されるはずです。
また、最大 10 Gbps のインバウンドをストレージ アカウントに移動することもできます。新しい 8 コア 56 GB マシンの最大NIC 帯域幅が 2 Gbps であることを考慮すると、その制限に近づくには、同時に実行する 5 つのマシンが必要です。シングルコア VM (コアあたり 100 Mbps) では、ストレージ アカウントのイングレス帯域幅の可能性を飽和させるために、100 個のインスタンスが必要になります。
ストレージ アカウントの帯域幅に関するすべての詳細は、この記事にあります。