Service Bus メッセージングを使用したパフォーマンス向上のためのベスト プラクティスBest Practices for performance improvements using Service Bus Messaging

この記事では、ブローカー メッセージを交換する際のパフォーマンスを Azure Service Bus を使用して最適化する方法について説明しています。This article describes how to use Azure Service Bus to optimize performance when exchanging brokered messages. この記事の前半では、パフォーマンスの向上に役立つさまざまなメカニズムについて説明します。The first part of this article describes the different mechanisms that are offered to help increase performance. 後半では、特定のシナリオでパフォーマンスを最大限に高めるための Service Bus の使用方法に関するガイダンスを示します。The second part provides guidance on how to use Service Bus in a way that can offer the best performance in a given scenario.

この記事全体で、"クライアント" という用語は Service Bus にアクセスするすべてのエンティティを指します。Throughout this article, the term "client" refers to any entity that accesses Service Bus. クライアントは送信側または受信側の役割を実行できます。A client can take the role of a sender or a receiver. "送信側" という用語は、Service Bus キューまたはトピックのサブスクリプションにメッセージを送信する Service Bus キューまたはトピックのクライアントを指します。The term "sender" is used for a Service Bus queue or topic client that sends messages to a Service Bus queue or topic subscription. "受信側" という用語は、Service Bus キューまたはサブスクリプションからメッセージを受信する Service Bus キューまたはサブスクリプションのクライアントを指します。The term "receiver" refers to a Service Bus queue or subscription client that receives messages from a Service Bus queue or subscription.

以下のセクションでは、パフォーマンスを向上するために Service Bus で利用される概念をいくつか紹介します。These sections introduce several concepts that Service Bus uses to help boost performance.

プロトコルProtocols

Service Bus を使用すると、クライアントは次の 3 つのプロトコルのいずれかを使用してメッセージを送受信できます。Service Bus enables clients to send and receive messages via one of three protocols:

  1. Advanced Message Queuing Protocol (AMQP)Advanced Message Queuing Protocol (AMQP)
  2. Service Bus メッセージング プロトコル (SBMP)Service Bus Messaging Protocol (SBMP)
  3. HTTPHTTP

AMQP と SBMP は、メッセージング ファクトリが存在する限り、Service Bus への接続を維持するため、より効率的です。AMQP and SBMP are more efficient, because they maintain the connection to Service Bus as long as the messaging factory exists. また、バッチとプリフェッチも実装されます。It also implements batching and prefetching. 明示的に示されていない限り、この記事のすべてのコンテンツで AMQP または SBMP を使用するものとします。Unless explicitly mentioned, all content in this article assumes the use of AMQP or SBMP.

ファクトリとクライアントの再利用Reusing factories and clients

QueueClientMessageSender などの Service Bus クライアント オブジェクトは、接続の内部管理も提供する MessagingFactory オブジェクトにより作成されます。Service Bus client objects, such as QueueClient or MessageSender, are created through a MessagingFactory object, which also provides internal management of connections. メッセージを送信した後にメッセージ ファクトリ、またはキュー、トピック、サブスクリプションのクライアントを閉じ、次のメッセージを送信するときにこれらを再作成しないことが推奨されています。It is recommended that you do not close messaging factories or queue, topic, and subscription clients after you send a message, and then re-create them when you send the next message. メッセージング ファクトリを閉じると Service Bus サービスの接続が削除され、ファクトリを再作成すると新しい接続が確立されます。Closing a messaging factory deletes the connection to the Service Bus service, and a new connection is established when recreating the factory. 接続の確立は費用のかかる操作です。この操作は、同じファクトリとクライアント オブジェクトを複数の操作に再利用することで回避できます。Establishing a connection is an expensive operation that you can avoid by reusing the same factory and client objects for multiple operations. これらのクライアントオブジェクトは、同時実行の非同期操作のために、複数のスレッドから安全に使用できます。You can safely use these client objects for concurrent asynchronous operations and from multiple threads.

同時実行の操作Concurrent operations

操作 (送信、受信、削除など) には時間がかかります。Performing an operation (send, receive, delete, etc.) takes some time. この時間には、要求と応答の待機時間だけでなく、Service Bus サービスによる操作の処理時間も含まれます。This time includes the processing of the operation by the Service Bus service in addition to the latency of the request and the reply. 時間あたりの操作数を増やすには、操作を同時に実行する必要があります。To increase the number of operations per time, operations must execute concurrently.

クライアントは非同期操作を実行することによって、同時実行操作のスケジュールを設定します。The client schedules concurrent operations by performing asynchronous operations. 前の要求が完了する前に次の要求が開始されます。The next request is started before the previous request is completed. 次のコード スニペットは、非同期送信操作の例です。The following code snippet is an example of an asynchronous send operation:

 Message m1 = new BrokeredMessage(body);
 Message m2 = new BrokeredMessage(body);
 
 Task send1 = queueClient.SendAsync(m1).ContinueWith((t) => 
   {
     Console.WriteLine("Sent message #1");
   });
 Task send2 = queueClient.SendAsync(m2).ContinueWith((t) => 
   {
     Console.WriteLine("Sent message #2");
   });
 Task.WaitAll(send1, send2);
 Console.WriteLine("All messages sent");

次のコードは、非同期受信操作の例です。The following code is an example of an asynchronous receive operation. 完全なプログラムはこちらを参照してください。See the full program here:

var receiver = new MessageReceiver(connectionString, queueName, ReceiveMode.PeekLock);
var doneReceiving = new TaskCompletionSource<bool>();

receiver.RegisterMessageHandler(...);

受信モードReceive mode

キューまたはサブスクリプションのクライアントを作成するときに、受信モードとして、"ピーク/ロック" または "受信して削除" を指定できます。When creating a queue or subscription client, you can specify a receive mode: Peek-lock or Receive and Delete. 既定の受信モードは PeekLock です。The default receive mode is PeekLock. このモードで操作するとき、クライアントは Service Bus からメッセージを受信する要求を送信します。When operating in this mode, the client sends a request to receive a message from Service Bus. クライアントはメッセージを受信した後で、メッセージを完了する要求を送信します。After the client has received the message, it sends a request to complete the message.

受信モードを ReceiveAndDelete に設定すると、1 つの要求に両方の手順が連結されます。When setting the receive mode to ReceiveAndDelete, both steps are combined in a single request. これらの手順によって、操作全体の数が削減され、全体的なメッセージ スループットを改善できます。These steps reduce the overall number of operations, and can improve the overall message throughput. この方法でパフォーマンスを改善すると、メッセージを失うリスクが生じます。This performance gain comes at the risk of losing messages.

Service Bus は "受信して削除" 操作のトランザクションをサポートしません。Service Bus does not support transactions for receive-and-delete operations. また、クライアントでメッセージの遅延または配信不能が必要なシナリオではピーク/ロック セマンティクスが必要になります。In addition, peek-lock semantics are required for any scenarios in which the client wants to defer or dead-letter a message.

クライアント側のバッチ処理Client-side batching

クライアント側のバッチ処理により、キューまたはトピックのクライアントはメッセージの送信を一定期間遅らせることができます。Client-side batching enables a queue or topic client to delay the sending of a message for a certain period of time. クライアントがこの期間内に追加のメッセージを送信すると、1 つのバッチで複数のメッセージが送信されます。If the client sends additional messages during this time period, it transmits the messages in a single batch. また、クライアント側のバッチ処理では、キューまたはサブスクリプションのクライアントが、複数の完了要求を 1 つの要求でバッチ処理します。Client-side batching also causes a queue or subscription client to batch multiple Complete requests into a single request. バッチ処理を使用できるのは、非同期の送信完了操作のみです。Batching is only available for asynchronous Send and Complete operations. 同期操作はすぐに Service Bus サービスに送信されます。Synchronous operations are immediately sent to the Service Bus service. バッチ処理はピーク操作や受信操作では行われません。また、クライアント間でも行われません。Batching does not occur for peek or receive operations, nor does batching occur across clients.

既定では、クライアントは 20 ミリ秒のバッチ間隔を使用します。By default, a client uses a batch interval of 20 ms. バッチ間隔を変更するには、メッセージング ファクトリを作成する前に BatchFlushInterval プロパティを設定します。You can change the batch interval by setting the BatchFlushInterval property before creating the messaging factory. この設定は、このファクトリによって作成されるすべてのクライアントに影響します。This setting affects all clients that are created by this factory.

バッチ処理を無効にするには、BatchFlushInterval プロパティを TimeSpan.Zero に設定します。To disable batching, set the BatchFlushInterval property to TimeSpan.Zero. 例:For example:

MessagingFactorySettings mfs = new MessagingFactorySettings();
mfs.TokenProvider = tokenProvider;
mfs.NetMessagingTransportSettings.BatchFlushInterval = TimeSpan.FromSeconds(0.05);
MessagingFactory messagingFactory = MessagingFactory.Create(namespaceUri, mfs);

バッチ処理は課金対象のメッセージ操作数に影響を与えません。また、Microsoft.ServiceBus.Messaging ライブラリを使用する Service Bus クライアント プロトコルでのみ利用できます。Batching does not affect the number of billable messaging operations, and is available only for the Service Bus client protocol using the Microsoft.ServiceBus.Messaging library. HTTP プロトコルはバッチ処理をサポートしません。The HTTP protocol does not support batching.

注意

BatchFlushInterval を設定すると、確実に、アプリケーションの観点からバッチ処理が暗黙的に実行されます。Setting BatchFlushInterval ensures that the batching is implicit from the application's perspective. つまり、アプリケーションにより SendAsync () および CompleteAsync () の呼び出しが行われ、特定の Batch の呼び出しは行われません。i.e. The application makes SendAsync() and CompleteAsync() calls and does not make specific Batch calls.

明示的なクライアント側のバッチ処理は、以下のメソッド呼び出しを利用して実装できます。Explicit client side batching can be implemented by utilizing the below method call -

Task SendBatchAsync (IEnumerable<BrokeredMessage> messages);

このメッセージの合計サイズは、価格レベルでサポートされている最大サイズより小さい必要があります。Here the combined size of the messages must be less than the maximum size supported by the pricing tier.

ストア アクセスのバッチ処理Batching store access

キュー、トピック、またはサブスクリプションのスループットを高めるために、Service Bus はその内部ストアに書き込む際に複数のメッセージをバッチ処理します。To increase the throughput of a queue, topic, or subscription, Service Bus batches multiple messages when it writes to its internal store. キューまたはトピックで有効になっている場合、ストアへのメッセージ書き込みがバッチ処理されます。If enabled on a queue or topic, writing messages into the store will be batched. キューまたはサブスクリプションで有効になっている場合、ストアからのメッセージ削除がバッチ処理されます。If enabled on a queue or subscription, deleting messages from the store will be batched. エンティティのバッチ処理ストア アクセスが有効になっている場合、Service Bus はそのエンティティに関するストア書き込み操作を最大 20 ミリ秒遅らせます。If batched store access is enabled for an entity, Service Bus delays a store write operation regarding that entity by up to 20 ms.

注意

20 ミリ秒のバッチ処理間隔の終了時に Service Bus でエラーがあった場合でも、バッチ処理のメッセージが失われるリスクがありません。There is no risk of losing messages with batching, even if there is a Service Bus failure at the end of a 20ms batching interval.

この間隔中に発生した追加のストアの操作はバッチに追加されます。Additional store operations that occur during this interval are added to the batch. バッチ処理ストア アクセスは送信操作と完了操作にのみ影響を与えます。受信操作には影響を与えません。Batched store access only affects Send and Complete operations; receive operations are not affected. バッチ処理ストア アクセスはエンティティのプロパティです。Batched store access is a property on an entity. バッチ処理は、バッチ処理ストア アクセスが有効になっているすべてのエンティティで発生します。Batching occurs across all entities that enable batched store access.

新しいキュー、トピック、サブスクリプションを作成すると、バッチ処理ストア アクセスは既定で有効になります。When creating a new queue, topic or subscription, batched store access is enabled by default. バッチ処理ストア アクセスを無効にするには、エンティティを作成する前に EnableBatchedOperations プロパティを false に設定します。To disable batched store access, set the EnableBatchedOperations property to false before creating the entity. 例:For example:

QueueDescription qd = new QueueDescription();
qd.EnableBatchedOperations = false;
Queue q = namespaceManager.CreateQueue(qd);

バッチ処理ストア アクセスは課金対象のメッセージ操作の数には影響を与えない、キュー、トピック、サブスクリプションのプロパティです。Batched store access does not affect the number of billable messaging operations, and is a property of a queue, topic, or subscription. 受信モードから独立しており、クライアントと Service Bus サービスの間で使用されるプロトコルです。It is independent of the receive mode and the protocol that is used between a client and the Service Bus service.

プリフェッチPrefetching

プリフェッチにより、キューまたはサブスクリプションのクライアントは受信操作の実行時にサービスから追加のメッセージを読み込むことができます。Prefetching enables the queue or subscription client to load additional messages from the service when it performs a receive operation. クライアントはこれらのメッセージをローカル キャッシュに格納します。The client stores these messages in a local cache. キャッシュのサイズは QueueClient.PrefetchCount プロパティまたは SubscriptionClient.PrefetchCount プロパティによって決まります。The size of the cache is determined by the QueueClient.PrefetchCount or SubscriptionClient.PrefetchCount properties. プリフェッチが有効になっているクライアントはそれぞれ独自のキャッシュを保持します。Each client that enables prefetching maintains its own cache. キャッシュはクライアント間で共有されません。A cache is not shared across clients. クライアントが受信操作を開始するときに、そのクライアントのキャッシュが空の場合、サービスはメッセージのバッチを送信します。If the client initiates a receive operation and its cache is empty, the service transmits a batch of messages. バッチのサイズは、キャッシュのサイズと 256 KB のうちの少ない方と等しくなります。The size of the batch equals the size of the cache or 256 KB, whichever is smaller. クライアントが受信操作を開始するときに、そのクライアントのキャッシュにメッセージが含まれている場合、キャッシュからメッセージが取得されます。If the client initiates a receive operation and the cache contains a message, the message is taken from the cache.

メッセージがプリフェッチされると、サービスはプリフェッチされたメッセージをロックします。When a message is prefetched, the service locks the prefetched message. このロックにより、別の受信側はプリフェッチされたメッセージを受信できなくなります。With the lock, the prefetched message cannot be received by a different receiver. 受信側がメッセージを完了できない状態でロックの有効期限が切れた場合、他の受信側がメッセージを受信できるようになります。If the receiver cannot complete the message before the lock expires, the message becomes available to other receivers. プリフェッチされたメッセージのコピーはキャッシュに残ります。The prefetched copy of the message remains in the cache. 受信側が有効期限の切れたキャッシュのコピーを使用している場合、そのメッセージを完了しようとしたときに例外を受け取ります。The receiver that consumes the expired cached copy will receive an exception when it tries to complete that message. 既定では、メッセージのロックは 60 秒後に期限切れになります。By default, the message lock expires after 60 seconds. この値は 5 分まで拡張できます。This value can be extended to 5 minutes. 期限切れのメッセージの使用を防ぐには、キャッシュ サイズを常に、ロックのタイムアウト間隔内にクライアントが使用できるメッセージの数より小さくする必要があります。To prevent the consumption of expired messages, the cache size should always be smaller than the number of messages that can be consumed by a client within the lock time-out interval.

60 秒間の既定のロック有効期限を使用する場合、PrefetchCount の適切な値はファクトリの全受信側の最大処理レートの 20 倍になります。When using the default lock expiration of 60 seconds, a good value for PrefetchCount is 20 times the maximum processing rates of all receivers of the factory. たとえば、ファクトリが 3 つの受信側を作成すると、各受信側は 1 秒あたり最大 10 個のメッセージを処理できます。For example, a factory creates three receivers, and each receiver can process up to 10 messages per second. プリフェッチ数が 20 X 3 X 10 = 600 を超えないようにしてください。The prefetch count should not exceed 20 X 3 X 10 = 600. 既定では、PrefetchCount は 0 に設定されます。これはサービスから追加のメッセージがフェッチされないことを意味します。By default, PrefetchCount is set to 0, which means that no additional messages are fetched from the service.

メッセージをプリフェッチすると、メッセージ操作全体の数、つまりラウンド トリップが減るため、キューまたはサブスクリプションの全体でのスループットが増えます。Prefetching messages increases the overall throughput for a queue or subscription because it reduces the overall number of message operations, or round trips. ただし、最初のメッセージのフェッチには (メッセージ サイズの増加に起因して) 時間がかかります。Fetching the first message, however, will take longer (due to the increased message size). プリフェッチ済みのメッセージは、クライアントが既にダウンロードしているため、速く受信できます。Receiving prefetched messages will be faster because these messages have already been downloaded by the client.

サーバーがクライアントにメッセージを送信するとき、メッセージの有効期間 (TTL) プロパティがサーバーによりチェックされます。The time-to-live (TTL) property of a message is checked by the server at the time the server sends the message to the client. クライアントは、メッセージを受信するときに、メッセージの TTL プロパティをチェックしません。The client does not check the message’s TTL property when the message is received. 代わりに、メッセージがクライアントによりキャッシュされたときにメッセージの TTL を経過している場合でも、メッセージを受信できます。Instead, the message can be received even if the message’s TTL has passed while the message was cached by the client.

プリフェッチは課金対象のメッセージ操作数に影響を与えません。また、Service Bus クライアント プロトコルでのみ利用できます。Prefetching does not affect the number of billable messaging operations, and is available only for the Service Bus client protocol. HTTP プロトコルはプリフェッチをサポートしません。The HTTP protocol does not support prefetching. プリフェッチは同期受信操作と非同期受信操作の両方で使用できます。Prefetching is available for both synchronous and asynchronous receive operations.

プリフェッチと ReceiveBatchPrefetching and ReceiveBatch

複数のメッセージをまとめてプリフェッチするという概念はメッセージのバッチ処理 (ReceiveBatch) と似ていますが、いくつかの小さな違いがあり、これらを一緒に使用する場合には覚えておく必要があります。While the concepts of prefetching multiple messages together have similar semantics to processing messages in a batch (ReceiveBatch), there are some minor differences that must be kept in mind when leveraging these together.

プリフェッチはクライアント (QueueClient と SubscriptionClient) 上での構成 (つまりモード) であり、ReceiveBatch は (要求 - 応答のセマンティクスが含まれる) 操作です。Prefetch is a configuration (or mode) on the client (QueueClient and SubscriptionClient) and ReceiveBatch is an operation (that has request-response semantics).

これらを一緒に使用する場合には、次のケースを考慮してください。While using these together, consider the following cases -

  • プリフェッチは、ReceiveBatch で受信が予想されるメッセージ数と同じか、それよりも多くする必要があります。Prefetch should be greater than or equal to the number of messages you are expecting to receive from ReceiveBatch.
  • プリフェッチは、1 秒あたりに処理されるメッセージ数の最大で n/3 倍にすることができます。n は既定のロック期間です。Prefetch can be up to n/3 times the number of messages processed per second, where n is the default lock duration.

欲張った方法 (プリフェッチ数を非常に多くするなど) を使用することにはいくつか課題があります。メッセージが特定の受信者にロックされることになるためです。There are some challenges with having a greedy approach(i.e. keeping the prefetch count very high), because it implies that the message is locked to a particular receiver. 上で説明したしきい値の間にある値でプリフェッチして、どれくらいが適しているかを経験的に特定することをお勧めします。The recommendation is to try out prefetch values between the thresholds mentioned above and empirically identify what fits.

複数のキューMultiple queues

予想される負荷を 1 つのキューまたはトピックで処理できない場合、複数のメッセージング エンティティを使用する必要があります。If the expected load cannot be handled by a single queue or topic, you must use multiple messaging entities. 複数のエンティティを使用するときは、すべてのエンティティに同じクライアントを使用するのではなく、エンティティごとに専用のクライアントを作成します。When using multiple entities, create a dedicated client for each entity, instead of using the same client for all entities.

開発およびテストの機能Development and testing features

Service Bus には、開発専用に使用され、運用環境の構成では絶対に使用しないようにする必要がある機能が 1 つあります。それは、TopicDescription.EnableFilteringMessagesBeforePublishing です。Service Bus has one feature, used specifically for development, which should never be used in production configurations: TopicDescription.EnableFilteringMessagesBeforePublishing.

新しい規則またはフィルターをトピックに追加したときに、TopicDescription.EnableFilteringMessagesBeforePublishing を使用して、新しいフィルター式が予想どおりに動作していることを確認できます。When new rules or filters are added to the topic, you can use TopicDescription.EnableFilteringMessagesBeforePublishing to verify that the new filter expression is working as expected.

シナリオScenarios

次のセクションでは、一般的なメッセージング シナリオについて説明し、好ましい Service Bus 設定について概要を説明します。The following sections describe typical messaging scenarios and outline the preferred Service Bus settings. スループット レートは小 (1 メッセージ/秒未満)、中 (1 メッセージ/秒以上、100 メッセージ/秒未満)、高 (100 メッセージ/秒以上) に分類されます。Throughput rates are classified as small (less than 1 message/second), moderate (1 message/second or greater but less than 100 messages/second) and high (100 messages/second or greater). クライアントの数は小 (5 以下)、中 (5 より大きく 20 以下)、大 (20 より大きい) に分類されます。The number of clients are classified as small (5 or fewer), moderate (more than 5 but less than or equal to 20), and large (more than 20).

高スループット キューHigh-throughput queue

目標: 1 つのキューのスループットを最大にします。Goal: Maximize the throughput of a single queue. 送信側と受信側の数は小です。The number of senders and receivers is small.

  • キューへの全体的な送信レートを上げるには、複数のメッセージ ファクトリを使用して送信側を作成します。To increase the overall send rate into the queue, use multiple message factories to create senders. 送信側ごとに、非同期操作または複数のスレッドを使用します。For each sender, use asynchronous operations or multiple threads.
  • キューからの全体的な受信レートを上げるには、複数のメッセージ ファクトリを使用して受信側を作成します。To increase the overall receive rate from the queue, use multiple message factories to create receivers.
  • クライアント側のバッチ処理を活用するには非同期操作を使用します。Use asynchronous operations to take advantage of client-side batching.
  • バッチ処理間隔を 50 ミリ秒に設定して、Service Bus クライアント プロトコル伝送の数を減らします。Set the batching interval to 50 ms to reduce the number of Service Bus client protocol transmissions. 複数の送信側を使用する場合は、バッチ処理の間隔を 100 ミリ秒に増やします。If multiple senders are used, increase the batching interval to 100 ms.
  • バッチ処理ストア アクセスを有効なままにします。Leave batched store access enabled. このアクセスにより、メッセージをキューに書き込む全体的なレートが上がります。This access increases the overall rate at which messages can be written into the queue.
  • プリフェッチ数をファクトリの全受信側の最大処理レートの 20 倍に設定します。Set the prefetch count to 20 times the maximum processing rates of all receivers of a factory. この数の設定によって、Service Bus クライアント プロトコル伝送の数が減ります。This count reduces the number of Service Bus client protocol transmissions.

複数の高スループット キューMultiple high-throughput queues

目標: 複数のキューの全体的なスループットを最大にします。Goal: Maximize overall throughput of multiple queues. 個々のキューのスループットは中または高です。The throughput of an individual queue is moderate or high.

複数のキュー全体で最大のスループットを得るには、説明にある設定を使用し、1 つのキューのスループットを最大化します。To obtain maximum throughput across multiple queues, use the settings outlined to maximize the throughput of a single queue. また、複数のファクトリを使用し、複数のキューと送受信するクライアントを作成します。In addition, use different factories to create clients that send or receive from different queues.

低待機時間のキューLow latency queue

目標: キューまたはトピックのエンド ツー エンドの待機時間を最小限に抑えます。Goal: Minimize end-to-end latency of a queue or topic. 送信側と受信側の数は小です。The number of senders and receivers is small. キューのスループットは小または中です。The throughput of the queue is small or moderate.

  • クライアント側のバッチ処理を無効にします。Disable client-side batching. クライアントはすぐにメッセージを送信します。The client immediately sends a message.
  • バッチ処理ストア アクセスを無効にします。Disable batched store access. サービスはメッセージをストアに直ちに書き込みます。The service immediately writes the message to the store.
  • 1 つのクライアントを使用している場合、プリフェッチ数を受信側の処理レートの 20 倍に設定します。If using a single client, set the prefetch count to 20 times the processing rate of the receiver. 複数のメッセージが同時にキューに到着すると、Service Bus クライアント プロトコルはそれらすべてを同時に送信します。If multiple messages arrive at the queue at the same time, the Service Bus client protocol transmits them all at the same time. クライアントが次のメッセージを受信するとき、そのメッセージは既にローカル キャッシュにあります。When the client receives the next message, that message is already in the local cache. キャッシュは小にします。The cache should be small.
  • 複数のクライアントを使用している場合、プリフェッチ数を 0 に設定します。If using multiple clients, set the prefetch count to 0. この数を設定することで、最初のクライアントが最初のメッセージを処理している間に、2 番目のクライアントは 2 番目のメッセージを受信できます。By setting the count, the second client can receive the second message while the first client is still processing the first message.

送信側の数が多いキューQueue with a large number of senders

目標: 送信側の数が多いキューまたはトピックのスループットを最大にします。Goal: Maximize throughput of a queue or topic with a large number of senders. 送信側はそれぞれ中程度のレートでメッセージを送信します。Each sender sends messages with a moderate rate. 受信側の数は小です。The number of receivers is small.

Service Bus によって、メッセージング エンティティに最大 1000 (または AMQP 使用で 5000) 件コンカレント接続できます。Service Bus enables up to 1000 concurrent connections to a messaging entity (or 5000 using AMQP). この制限は名前空間レベルで適用され、キュー、トピック、サブスクリプションは名前空間あたりのコンカレント接続数の上限によって制限されます。This limit is enforced at the namespace level, and queues/topics/subscriptions are capped by the limit of concurrent connections per namespace. キューの場合、この数は送信側と受信側で共有されます。For queues, this number is shared between senders and receivers. 1000 件の接続すべてが送信側で必要な場合は、キューをトピックと 1 つのサブスクリプションで置き換えます。If all 1000 connections are required for senders, replace the queue with a topic and a single subscription. トピックは送信側から最大 1000 件のコンカレント接続を受け入れるのに対して、サブスクリプションは受信側からさらに 1000 件のコンカレント接続を受け入れます。A topic accepts up to 1000 concurrent connections from senders, whereas the subscription accepts an additional 1000 concurrent connections from receivers. 1000 件を超える同時接続が送信側で必要な場合は、送信側は HTTP 経由で Service Bus プロトコルにメッセージを送信する必要があります。If more than 1000 concurrent senders are required, the senders should send messages to the Service Bus protocol via HTTP.

スループットを最大化するには、次の手順を実行します。To maximize throughput, perform the following steps:

  • 各送信側が異なるプロセスに存在する場合、プロセスごとに 1 つのファクトリのみを使用します。If each sender resides in a different process, use only a single factory per process.
  • クライアント側のバッチ処理を活用するには非同期操作を使用します。Use asynchronous operations to take advantage of client-side batching.
  • 20 ミリ秒の既定のバッチ処理間隔を使用して、Service Bus クライアント プロトコル伝送の数を減らします。Use the default batching interval of 20 ms to reduce the number of Service Bus client protocol transmissions.
  • バッチ処理ストア アクセスを有効なままにします。Leave batched store access enabled. このアクセスによって、メッセージをキューまたはトピックに書き込む全体的なレートが上がります。This access increases the overall rate at which messages can be written into the queue or topic.
  • プリフェッチ数をファクトリの全受信側の最大処理レートの 20 倍に設定します。Set the prefetch count to 20 times the maximum processing rates of all receivers of a factory. この数の設定によって、Service Bus クライアント プロトコル伝送の数が減ります。This count reduces the number of Service Bus client protocol transmissions.

受信側の数が多いキューQueue with a large number of receivers

目標: 受信側の数が多いキューまたはサブスクリプションの受信レートを最大にします。Goal: Maximize the receive rate of a queue or subscription with a large number of receivers. 各受信側は中程度のレートでメッセージを受信します。Each receiver receives messages at a moderate rate. 送信側の数は小です。The number of senders is small.

Service Bus によって、エンティティに最大 1000 件コンカレント接続できるようになります。Service Bus enables up to 1000 concurrent connections to an entity. キューが 1000 件を超える受信側を必要とする場合は、キューをトピックと複数のサブスクリプションで置き換えます。If a queue requires more than 1000 receivers, replace the queue with a topic and multiple subscriptions. 各サブスクリプションは最大 1000 件のコンカレント接続をサポートします。Each subscription can support up to 1000 concurrent connections. または、受信側は HTTP プロトコル経由でキューにアクセスできます。Alternatively, receivers can access the queue via the HTTP protocol.

スループットを最大化するには、次の手順を実行します。To maximize throughput, do the following:

  • 各受信側が異なるプロセスに存在する場合、プロセスごとに 1 つのファクトリのみを使用します。If each receiver resides in a different process, use only a single factory per process.
  • 受信側は同期操作または非同期操作を使用できます。Receivers can use synchronous or asynchronous operations. 各受信側の受信レートを中にすると、受信側のスループットは完了要求のクライアント側のバッチ処理の影響を受けません。Given the moderate receive rate of an individual receiver, client-side batching of a Complete request does not affect receiver throughput.
  • バッチ処理ストア アクセスを有効なままにします。Leave batched store access enabled. このアクセスによって、エンティティ全体の負荷が軽減されます。This access reduces the overall load of the entity. これにより、メッセージをキューまたはトピックに書き込む全体的なレートも下がります。It also reduces the overall rate at which messages can be written into the queue or topic.
  • プリフェッチ数を小さい値 (PrefetchCount = 10 など) に設定します。Set the prefetch count to a small value (for example, PrefetchCount = 10). この数の設定によって、他の受信側が大量のメッセージをキャッシュしている間に受信側がアイドル状態になることを防止できます。This count prevents receivers from being idle while other receivers have large numbers of messages cached.

サブスクリプションの数が少ないトピックTopic with a small number of subscriptions

目標: サブスクリプションの数が少ないトピックのスループットを最大にします。Goal: Maximize the throughput of a topic with a small number of subscriptions. メッセージは多くのサブスクリプションで受信されます。これはすべてのサブスクリプションの受信レートを合わせると送信レートを超えることを意味します。A message is received by many subscriptions, which means the combined receive rate over all subscriptions is larger than the send rate. 送信側の数は小です。The number of senders is small. サブスクリプションあたりの受信側の数は小です。The number of receivers per subscription is small.

スループットを最大化するには、次の手順を実行します。To maximize throughput, do the following:

  • トピックへの全体的な送信レートを上げるには、複数のメッセージ ファクトリを使用して送信側を作成します。To increase the overall send rate into the topic, use multiple message factories to create senders. 送信側ごとに、非同期操作または複数のスレッドを使用します。For each sender, use asynchronous operations or multiple threads.
  • サブスクリプションからの全体的な受信レートを上げるには、複数のメッセージ ファクトリを使用して受信側を作成します。To increase the overall receive rate from a subscription, use multiple message factories to create receivers. 受信側ごとに、非同期操作または複数のスレッドを使用します。For each receiver, use asynchronous operations or multiple threads.
  • クライアント側のバッチ処理を活用するには非同期操作を使用します。Use asynchronous operations to take advantage of client-side batching.
  • 20 ミリ秒の既定のバッチ処理間隔を使用して、Service Bus クライアント プロトコル伝送の数を減らします。Use the default batching interval of 20 ms to reduce the number of Service Bus client protocol transmissions.
  • バッチ処理ストア アクセスを有効なままにします。Leave batched store access enabled. このアクセスによって、メッセージをトピックに書き込む全体的なレートが上がります。This access increases the overall rate at which messages can be written into the topic.
  • プリフェッチ数をファクトリの全受信側の最大処理レートの 20 倍に設定します。Set the prefetch count to 20 times the maximum processing rates of all receivers of a factory. この数の設定によって、Service Bus クライアント プロトコル伝送の数が減ります。This count reduces the number of Service Bus client protocol transmissions.

サブスクリプションの数が多いトピックTopic with a large number of subscriptions

目標: サブスクリプションの数が多いトピックのスループットを最大にします。Goal: Maximize the throughput of a topic with a large number of subscriptions. メッセージは多くのサブスクリプションで受信されます。これはすべてのサブスクリプションの受信レートを合わせると送信レートをはるかに超えることを意味します。A message is received by many subscriptions, which means the combined receive rate over all subscriptions is much larger than the send rate. 送信側の数は小です。The number of senders is small. サブスクリプションあたりの受信側の数は小です。The number of receivers per subscription is small.

すべてのメッセージがすべてのサブスクリプションに送信される場合、通常、多数のサブスクリプションを含むトピックの全体的なスループットは低下します。Topics with a large number of subscriptions typically expose a low overall throughput if all messages are routed to all subscriptions. スループットが低下する原因は、各メッセージが数回受信され、トピックとそのすべてのサブスクリプションに含まれるメッセージがすべて同じストアに保存されることにあります。This low throughput is caused by the fact that each message is received many times, and all messages that are contained in a topic and all its subscriptions are stored in the same store. サブスクリプションあたりの送信側の数と受信側の数は小であるとします。It is assumed that the number of senders and number of receivers per subscription is small. Service Bus はトピックあたり最大 2,000 のサブスクリプションをサポートします。Service Bus supports up to 2,000 subscriptions per topic.

スループットを最大化するには、次の手順を試します。To maximize throughput, try the following steps:

  • クライアント側のバッチ処理を活用するには非同期操作を使用します。Use asynchronous operations to take advantage of client-side batching.
  • 20 ミリ秒の既定のバッチ処理間隔を使用して、Service Bus クライアント プロトコル伝送の数を減らします。Use the default batching interval of 20 ms to reduce the number of Service Bus client protocol transmissions.
  • バッチ処理ストア アクセスを有効なままにします。Leave batched store access enabled. このアクセスによって、メッセージをトピックに書き込む全体的なレートが上がります。This access increases the overall rate at which messages can be written into the topic.
  • プリフェッチ数を予想される受信レート (秒単位) の 20 倍に設定します。Set the prefetch count to 20 times the expected receive rate in seconds. この数の設定によって、Service Bus クライアント プロトコル伝送の数が減ります。This count reduces the number of Service Bus client protocol transmissions.