Skip to content

Commit 39c5e0d

Browse files
authored
Merge pull request #124424 from udidahan/patch-3
Additional useful metric for scaling
2 parents 26bb8a6 + 6b6ce19 commit 39c5e0d

File tree

1 file changed

+2
-0
lines changed

1 file changed

+2
-0
lines changed

articles/service-bus-messaging/message-counters.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -20,6 +20,8 @@ This article shows you different ways of getting message counts for a queue or s
2020

2121
If an application wants to scale resources based on the length of the queue, it should do so with a measured pace. The acquisition of the message counters is an expensive operation inside the message broker, and executing it frequently directly and adversely impacts the entity performance.
2222

23+
Another useful metric to consider for scaling is the time between when the latest message was sent and when it was processed, also known as "critical time". This is helpful for scenarios where a queue may have thousands of messages in it, but the processing is fast enough to keep up, giving a "critical time" of only a couple of seconds, which may be more than enough for something like an email sending endpoint. Third-party libraries like [NServiceBus](https://docs.particular.net/nservicebus/operations/opentelemetry#meters-emitted-meters) emit this and other useful metrics via OpenTelemetry.
24+
2325
> [!NOTE]
2426
> The messages that are sent to a Service Bus topic are forwarded to subscriptions for that topic. So, the active message count on the topic itself is 0, as those messages have been successfully forwarded to the subscription. Get the message count at the subscription and verify that it's greater than 0. Even though you see messages at the subscription, they are actually stored in a storage owned by the topic. If you look at the subscriptions, then they would have non-zero message count (which add up to 323 MB of space for this entire entity).
2527

0 commit comments

Comments
 (0)