How to address the latency issues when pushing messages to Azure Service Bus queue

Question

How to address the latency issues when pushing messages to Azure Service Bus queue

Vijay Myadam (myadam) 0

We have recently integrated to process messages using Azure service bus. We are using Azure Service Bus premium tier, pushing messages from Legacy (.NET FRAME WORK 4.8) SOAP API. Few messages pushed to queue quickly but when load is increased requests get more time to push the messages. On some occasions it took more than 110 seconds and getting timedout.

Application : Legacy SOAP API
Running : .NET framework 4.8
Azure Service bus premium tier
Using User Managed identity to connect.

Vinayteja Lellela 110 Reputation points Microsoft External Staff Moderator

2026-05-17T10:20:32.4633333+00:00
Hey Vijay, it sounds like under heavier load your .NET 4.8 SOAP API is seeing timeouts (110 s+) when calling into your Premium-tier Service Bus queue. Here are some things to try based on Microsoft’s best-practices guidance:

Use the most efficient protocol & SDK

• Ensure you’re on AMQP (not HTTP or SBMP). AMQP keeps connections open and supports batching/prefetching.

• If you’re still on the old WindowsAzure.ServiceBus package, consider migrating to the newer Azure.Messaging.ServiceBus (.NET Standard) SDK.

Optimize your client usage

• Create and reuse a single ServiceBusClient per process—don’t spin up a new client/sender for every message.

• Use asynchronous send calls (SendMessageAsync) rather than blocking synchronous ones.

• Parallelize at the sender: spawn multiple tasks/threads each using its own ServiceBusSender to push messages concurrently.

Scale out your Premium namespace

• Increase your messaging units to raise overall throughput.

• If you have hot-spot issues, enable partitioning on your queue or namespace so load is spread across multiple message brokers.

Implement retry & back-off logic

• Service Bus will throttle you under high CPU/memory. Catch server-busy (HTTP 429) or Throttling exceptions and retry after 10 seconds (at minimum), with exponential back-off.

Monitor & benchmark

• Turn on Service Bus metrics (incoming requests, successful requests, throttled requests, egress bytes, CPU, memory) and look for spikes or throttle events.

• Compare your observed throughput with the published Service Bus benchmarks to see if you’re hitting expected limits.

Hope this helps! If you still see high latency, let us know more about:

• Which exact Service Bus client library & version you’re using

• How many Messaging Units your Premium namespace is configured with

• Whether your queue is partitioned or not

• Your concurrency model: number of threads/tasks, SendAsync vs. sync calls

• Any throttling metrics you’re seeing in Azure Monitor

Reference list

Best Practices for performance improvements using Service Bus Messaging https://docs.microsoft.com/azure/service-bus-messaging/service-bus-performance-improvements?tabs=net-standard-sdk-2

Service Bus benchmarks https://docs.microsoft.com/azure/service-bus-messaging/service-bus-performance-improvements?tabs=net-standard-sdk-2#benchmarks

Throttling & retry guidance https://docs.microsoft.com/azure/service-bus-messaging/service-bus-async-messaging?tabs=azure-portal#failure-mode-types

Monitoring Service Bus metrics https://docs.microsoft.com/azure/service-bus-messaging/monitor-service-bus-reference

Partitioned entities overview https://docs.microsoft.com/azure/service-bus-messaging/service-bus-partitioning

Azure.Messaging.ServiceBus migration guide https://docs.microsoft.com/azure/service-bus-messaging/migrate-dotnet-framework-service-bus-sdk-to-azure-messaging-servicebus

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.
Vijay Myadam (myadam) 0 Reputation points

2026-05-20T21:11:02.7166667+00:00
Thank you for your suggestions regarding our Service Bus latency issues. We have thoroughly reviewed those recommendations; however, we have not yet identified the root cause of the delay.

Through our investigation, we have isolated a significant latency bottleneck during the initialization phase. We observed that creating the ServiceBusClient and ServiceBusSender objects occasionally takes more than 20 seconds.

Once the client and sender are successfully established, the subsequent operation of pushing a message to the Service Bus queue is very efficient, typically completing within 100 milliseconds.

Our Questions:

Is this initialization latency expected? Is a 20-second delay during the creation of the ServiceBusClient and ServiceBusSender considered within normal operating parameters for this SDK?

What is the "ideal" latency? What is the typical expected time for establishing a connection and initializing these objects?

Troubleshooting Guidance: Are there specific network or configuration factors (e.g., DNS resolution, authentication handshake, or connection pooling settings) that we should investigate to reduce this 20-second initialization time?

We are concerned that this connection-creation delay is the primary driver behind the message processing latency we are experiencing. Any guidance you can provide on optimizing this initialization process would be greatly appreciated.
Vinayteja Lellela 110 Reputation points Microsoft External Staff Moderator

2026-05-21T10:30:50.3+00:00
Hi Vijay Myadam,

Thank you for the detailed investigation and for isolating the delay during the initialization phase, that’s a very useful finding.

Is the 20-second initialization latency expected?

No, this is not expected behavior. Under normal conditions:

Initial client creation should typically take sub-second to a few seconds (cold start)

Sender creation is usually near-instant

Message send operations (as you observed) are typically tens to hundreds of milliseconds

A 20-second delay generally indicates overhead during connection establishment, authentication, or client lifecycle management, rather than Service Bus processing itself.

Likely cause of the latency

Based on your observations, the most probable cause is client initialization being repeated frequently.

If the ServiceBusClient, ServiceBusSender, or ManagedIdentityCredential objects are being created per request, this results in:

Repeated AMQP connection setup and TLS handshake

Repeated managed identity token acquisition (which involves an additional network call)

Loss of connection and token caching benefits

This overhead can significantly increase latency, especially under load.

Recommended approach to optimize initialization

Reuse Service Bus client and sender (critical)

Create the ServiceBusClient and ServiceBusSender once and reuse them for all operations. This allows connection pooling and reduces repeated initialization overhead.

Reuse Managed Identity credential

Ensure that a single instance of ManagedIdentityCredential is reused so that token caching works efficiently.

Avoid per-request initialization

Initializing Service Bus objects inside each SOAP request can lead to increased latency and timeouts. Instead, adopt a long-lived (singleton/static) pattern at the application level.

Validate network and transport configuration

Prefer AMQP over TCP (port 5671) instead of WebSockets (port 443), as WebSockets adds additional latency layers.

Check for DNS resolution delays, firewall rules, or proxy configurations that may impact connection setup.

Review retry and timeout settings

The default retry behavior may introduce longer delays under transient failures (each attempt can have significant timeout). Adjusting retry settings can help avoid compounded delays during initialization.

Monitor Service Bus metrics for validation

To confirm whether the issue is purely client-side vs service-side, monitor:

CPU and memory usage

Throttled requests

Send latency metrics

Azure Monitor provides visibility into these signals for troubleshooting performance and resource usage. [Monitor Az...soft Learn | Learn.Microsoft.com]

3 answers

Your answer

Vijay Myadam (myadam) 0 Reputation points

2026-05-20T21:11:02.7166667+00:00

Thank you for your suggestions regarding our Service Bus latency issues. We have thoroughly reviewed those recommendations; however, we have not yet identified the root cause of the delay.

Through our investigation, we have isolated a significant latency bottleneck during the initialization phase. We observed that creating the ServiceBusClient and ServiceBusSender objects occasionally takes more than 20 seconds.

Once the client and sender are successfully established, the subsequent operation of pushing a message to the Service Bus queue is very efficient, typically completing within 100 milliseconds.

Our Questions:

Is this initialization latency expected? Is a 20-second delay during the creation of the ServiceBusClient and ServiceBusSender considered within normal operating parameters for this SDK?

What is the "ideal" latency? What is the typical expected time for establishing a connection and initializing these objects?

Troubleshooting Guidance: Are there specific network or configuration factors (e.g., DNS resolution, authentication handshake, or connection pooling settings) that we should investigate to reduce this 20-second initialization time?

We are concerned that this connection-creation delay is the primary driver behind the message processing latency we are experiencing. Any guidance you can provide on optimizing this initialization process would be greatly appreciated.

Answer 1

Use the Premium tier features and client-side optimizations to remove the send latency bottleneck and avoid timeouts when load increases.

Validate capacity and tier usage

Premium provides dedicated messaging units (MUs). Each MU delivers about 4 MB/s of ingress and 4 MB/s of egress in benchmark tests.
If message size × send rate under load approaches or exceeds this per-MU throughput, increase the number of MUs or enable auto-scaling so the namespace can handle spikes without throttling.
Ensure the workload is actually using the Premium namespace (not a Standard one) and that auto-scaling is configured with appropriate minimum and maximum MUs.

Optimize client concurrency and async usage

High send latency often comes from serial, synchronous operations on the client side rather than the Service Bus itself.
Use asynchronous send APIs from the .NET client and schedule multiple concurrent send operations so that the next send starts before the previous one completes.
Run multiple concurrent senders (threads or tasks) instead of a single sender under load. This increases the number of operations per unit time and hides network latency.

Use batching for sends

Instead of sending one message per call, batch messages using the batch send APIs (for example, SendMessages() equivalents in the SDK).
Batching reduces network round trips and connection overhead, which significantly improves throughput and reduces per-message latency when load increases.

Tune connection and network behavior

Ensure connection pooling is enabled and reuse MessagingFactory/ServiceBusClient instances instead of creating them per request.
Co-locate the SOAP API compute (App Service, VM, etc.) in the same Azure region as the Service Bus Premium namespace to minimize network latency.
Verify there is no network bottleneck (firewall, proxy, or VPN) adding latency when many concurrent connections are opened.

Configure prefetch and receive patterns on consumers

If the queue is backing up because consumers are slow, send operations can be indirectly impacted by throttling or resource contention.
Use prefetch on receivers and multiple concurrent receivers to keep the queue depth under control and maintain steady throughput.

Monitor and detect throttling or bottlenecks

Use Azure Monitor metrics for the namespace to track:
- Message throughput (ingress/egress)
- Queue depth trends
- Throttling events and server errors
- Processing latency
If throttling is observed, increase MUs, enable/adjust auto-scaling, or distribute load across additional queues/namespaces.

Adjust timeout and retry behavior

Ensure the client uses the default retry policy for Service Bus so transient throttling or network delays do not immediately cause failures.
Set reasonable operation timeouts in the client; combine this with retries rather than a single long operation that times out at 110 seconds.

Capacity planning and load testing

Perform capacity planning based on expected peak message volume, size, and concurrency.
Use Azure Load Testing or similar tools to simulate realistic workloads and validate that the configured MUs, batching, and concurrency levels sustain the required throughput without hitting timeouts.

Applying these changes—Premium MU sizing/auto-scaling, async and concurrent sends, batching, regional co-location, and proper monitoring—will address the latency spikes when pushing messages under load.

References:

Answer 2

Hello Vijay Myadam (myadam),

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you need how to address the latency issues when pushing messages to Azure Service Bus queue.

In practice, this pattern is almost always caused by either (1) Premium namespace throttling/capacity pressure (Messaging Units CPU/memory) or (2) producer-side inefficiencies that most commonly recreating Service Bus clients/senders and/or managed identity credentials per request, which triggers connection churn and token acquisition overhead, amplified by the SDK’s retry/try-timeout behavior (default TryTimeout = 60 seconds per attempt). https://learn.microsoft.com/en-us/azure/service-bus-messaging/monitor-service-bus-reference, https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-throttling, https://learn.microsoft.com/en-us/dotnet/api/azure.messaging.servicebus.servicebusretryoptions.trytimeout?view=azure-dotnet, https://learn.microsoft.com/en-us/dotnet/api/azure.identity.managedidentitycredential?view=azure-dotnet

Follow the below steps to resolve it:

Validate whether the bottleneck is on the broker by checking ServerSendLatency, ThrottledRequests, NamespaceCpuUsage/MemoryUsage in Azure Monitor. - https://learn.microsoft.com/en-us/azure/service-bus-messaging/monitor-service-bus-reference, https://learn.microsoft.com/en-us/azure/service-bus-messaging/monitor-service-bus
If throttled, scale or autoscale Messaging Units for the Premium namespace (the supported and recommended way to restore predictable performance). - https://learn.microsoft.com/en-us/azure/service-bus-messaging/automate-update-messaging-units, https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-premium-messaging
Fix the producer pattern by keeping a single long-lived ServiceBusClient + ServiceBusSender (do not create/dispose per SOAP call), enabling batch sends, and reusing a single ManagedIdentityCredential instance so token caching works as designed. https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-performance-improvements, https://learn.microsoft.com/en-us/dotnet/api/overview/azure/messaging.servicebus-readme?view=azure-dotnet, https://learn.microsoft.com/en-us/dotnet/api/azure.identity.managedidentitycredential?view=azure-dotnet
Use AMQP over TCP (5671) unless your network requires WebSockets (443), because WebSockets is intended primarily for restricted networks and adds an extra transport layer. https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-amqp-protocol-guide, https://github.com/Azure/azure-sdk-for-net/issues/30270
Align retry/timeout settings to your API SLA (uncontrolled retries + 60s per-try timeout can produce “~110s” end-to-end delays that look like broker latency). https://learn.microsoft.com/en-us/dotnet/api/azure.messaging.servicebus.servicebusretryoptions.trytimeout?view=azure-dotnet, https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-throttling

After confirming broker health and applying the producer fix (client/credential reuse + batching + correct transport + SLA-aligned retry), send latency stabilizes under load and timeouts stop occurring in the SOAP request path. Use the associated links for steps, more reading and references.

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Answer 3

Thank you for your suggestions regarding our Service Bus latency issues. We have thoroughly reviewed those recommendations; however, we have not yet identified the root cause of the delay.

Through our investigation, we have isolated a significant latency bottleneck during the initialization phase. We observed that creating the ServiceBusClient and ServiceBusSender objects occasionally takes more than 20 seconds.

Once the client and sender are successfully established, the subsequent operation of pushing a message to the Service Bus queue is very efficient, typically completing within 100 milliseconds.

Our Questions:

Is this initialization latency expected? Is a 20-second delay during the creation of the ServiceBusClient and ServiceBusSender considered within normal operating parameters for this SDK?
What is the "ideal" latency? What is the typical expected time for establishing a connection and initializing these objects?
Troubleshooting Guidance: Are there specific network or configuration factors (e.g., DNS resolution, authentication handshake, or connection pooling settings) that we should investigate to reduce this 20-second initialization time?

We are concerned that this connection-creation delay is the primary driver behind the message processing latency we are experiencing. Any guidance you can provide on optimizing this initialization process would be greatly appreciated.