[QUERY] What is an acceptable range for MaxConcurrentSessions?

[andrewrimmer]

Library name and version

Azure.Messaging.ServiceBus 7.17.3

Query/Question

What is an acceptable range for MaxConcurrentSessions?

It defaults to 8 in this SDK but in the older SDK I think it is ProcessorCount * 1000, which for our server is 64,000

In our current scenario, we seem to get up to maybe 500 sessions and then we stop getting any more sessions (and messages). Our queue just continues building up. This is surprising, as I would think our server could handle a lot more open sessions if they are all just waiting for messages.

Our application ends up not doing any message processing, and just waiting for the sessions to timeout before it can process any more messages.

Is this expected behaviour?

Environment

Windows Server 2022
.net 8
2 Processors (16 cores/32 threads)
Azure Service Bus Premium

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[jsquire]

Hi @andrewrimmer. Thanks for reaching out and for your inquiry. This is not a question that can be answered authoritatively in a general way. The "acceptable range" is something that will depend heavily on the application, its environment, the type of processing done, the size/structure of the data, responsiveness of any downstream systems, other activities taking place on the host during processing, and a number of other factors.

The general guidance would be to choose a conservative value and test under real-world conditions. Monitor your resources, network congestion, and application performance, using those observations to tune your concurrency until you reach the desired results.

In our current scenario, we seem to get up to maybe 500 sessions and then we stop getting any more sessions (and messages). Our queue just continues building up. This is surprising, as I would think our server could handle a lot more open sessions if they are all just waiting for messages.

Remember that CPU utilization alone is not an accurate way to measure health of the host, particularly where concurrency is concerned. In a highly concurrent async application, you can often see a convoy of async continuations queued up and waiting for their chance to run. Because there's no fairness in thread pool scheduling, this leads to some parts of the system looking "stalled" while some may continue to make forward progress and seem ok.

Our application ends up not doing any message processing, and just waiting for the sessions to timeout before it can process any more messages.

This sounds very much like you're hitting resource issues either in the network or in the .NET thread pool. I'd suggest taking some memory dumps and analyzing the async stack, thread pool, and understanding the state of actively running threads to see where there may be a bottleneck.

Some additional discussion and resources for debugging can be found in this section of the Service Bus Troubleshooting Guide.

[github-actions]

Hi @andrewrimmer. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.