You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/service-bus-messaging/service-bus-performance-improvements.md
+4-3Lines changed: 4 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,6 +12,7 @@ ms.topic: article
12
12
ms.date: 03/12/2020
13
13
ms.author: aschhab
14
14
---
15
+
15
16
# Best Practices for performance improvements using Service Bus Messaging
16
17
17
18
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. The second part provides guidance on how to use Service Bus in a way that can offer the best performance in a given scenario.
@@ -26,7 +27,7 @@ Service Bus enables clients to send and receive messages via one of three protoc
26
27
27
28
1. Advanced Message Queuing Protocol (AMQP)
28
29
2. Service Bus Messaging Protocol (SBMP)
29
-
3. HTTP
30
+
3.Hypertext Transfer Protocol (HTTP)
30
31
31
32
AMQP is the most efficient, because it maintains the connection to Service Bus. It also implements batching and prefetching. Unless explicitly mentioned, all content in this article assumes the use of AMQP or SBMP.
32
33
@@ -267,7 +268,7 @@ When using the default lock expiration of 60 seconds, a good value for `Prefetch
267
268
268
269
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.
269
270
270
-
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. The client does not check the message’s TTL property when the message is received. Instead, the message can be received even if the message’s TTL has passed while the message was cached by the client.
271
+
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. The client does not check the message's TTL property when the message is received. Instead, the message can be received even if the message's TTL has passed while the message was cached by the client.
271
272
272
273
Prefetching does not affect the number of billable messaging operations, and is available only for the Service Bus client protocol. The HTTP protocol does not support prefetching. Prefetching is available for both synchronous and asynchronous receive operations.
273
274
@@ -411,4 +412,4 @@ To maximize throughput, try the following steps:
0 commit comments