|
2 | 2 | title: Best practices for improving performance using Azure Service Bus
|
3 | 3 | description: Describes how to use Service Bus to optimize performance when exchanging brokered messages.
|
4 | 4 | ms.topic: article
|
5 |
| -ms.date: 08/30/2021 |
| 5 | +ms.date: 01/24/2021 |
6 | 6 | ms.devlang: csharp
|
7 | 7 | ---
|
8 | 8 |
|
@@ -279,47 +279,6 @@ When setting the receive mode to `ReceiveAndDelete`, both steps are combined in
|
279 | 279 |
|
280 | 280 | Service Bus doesn't support transactions for receive-and-delete operations. Also, peek-lock semantics are required for any scenarios in which the client wants to defer or [dead-letter](service-bus-dead-letter-queues.md) a message.
|
281 | 281 |
|
282 |
| -## Client-side batching |
283 |
| - |
284 |
| -Client-side batching enables a queue or topic client to delay the sending of a message for a certain period of time. If the client sends additional messages during this time period, it transmits the messages in a single batch. 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. Synchronous operations are immediately sent to the Service Bus service. Batching doesn't occur for peek or receive operations, nor does batching occur across clients. |
285 |
| - |
286 |
| -# [Azure.Messaging.ServiceBus SDK](#tab/net-standard-sdk-2) |
287 |
| -Batching functionality for the .NET Standard SDK doesn't yet expose a property to manipulate. |
288 |
| - |
289 |
| -# [Microsoft.Azure.ServiceBus SDK](#tab/net-standard-sdk) |
290 |
| - |
291 |
| -Batching functionality for the .NET Standard SDK doesn't yet expose a property to manipulate. |
292 |
| - |
293 |
| -# [WindowsAzure.ServiceBus SDK](#tab/net-framework-sdk) |
294 |
| - |
295 |
| -By default, a client uses a batch interval of 20 ms. You can change the batch interval by setting the [BatchFlushInterval][BatchFlushInterval] property before creating the messaging factory. This setting affects all clients that are created by this factory. |
296 |
| - |
297 |
| -To disable batching, set the [BatchFlushInterval][BatchFlushInterval] property to **TimeSpan.Zero**. For example: |
298 |
| - |
299 |
| -```csharp |
300 |
| -var settings = new MessagingFactorySettings |
301 |
| -{ |
302 |
| - NetMessagingTransportSettings = |
303 |
| - { |
304 |
| - BatchFlushInterval = TimeSpan.Zero |
305 |
| - } |
306 |
| -}; |
307 |
| -var factory = MessagingFactory.Create(namespaceUri, settings); |
308 |
| -``` |
309 |
| - |
310 |
| -Batching doesn't affect the number of billable messaging operations, and is available only for the Service Bus client protocol using the [Microsoft.ServiceBus.Messaging](https://www.nuget.org/packages/WindowsAzure.ServiceBus/) library. The HTTP protocol doesn't support batching. |
311 |
| - |
312 |
| -> [!NOTE] |
313 |
| -> Setting `BatchFlushInterval` ensures that the batching is implicit from the application's perspective. i.e.; the application makes `SendAsync` and `CompleteAsync` calls and doesn't make specific Batch calls. |
314 |
| -> |
315 |
| -> Explicit client side batching can be implemented by utilizing the below method call: |
316 |
| -> ```csharp |
317 |
| -> Task SendBatchAsync(IEnumerable<BrokeredMessage> messages); |
318 |
| -> ``` |
319 |
| -> Here the combined size of the messages must be less than the maximum size supported by the pricing tier. |
320 |
| -
|
321 |
| ---- |
322 |
| -
|
323 | 282 | ## Batching store access
|
324 | 283 |
|
325 | 284 | To increase the throughput of a queue, topic, or subscription, Service Bus batches multiple messages when it writes to its internal store.
|
|
0 commit comments