Azure-docs: What is the point of maxConcurrentCalls?

[timmyreilly]

I'm having a tough time understanding the use case of maxConcurrentCalls, if the Functions runtime is going to scale from 0-1000+ instances what does it matter what I set the maxConcurrentCalls to?

I need a way of limiting how many messages from the service bus are processed at any given time. I'd like to limit the currently processed messages to 300 because my downstream server will start throwing errors if I scale out too quickly. Will setting maxConcurrentCalls do this? Or do I really need to spin up a premium function instance and set host limits? This seems like a lot of extra work just to slow something down.

Or is that what maxConcurrentCalls is designed to do? Limit the current number of messages locked by the currently processed functions.

I guess my feedback for this doc is: What does "The maximum number of concurrent calls to the callback that the message pump should initiate" mean?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 0440205f-adcc-0fc5-3adb-db4dbe1d1292
• Version Independent ID: 14ad1300-590c-8102-6887-366078e1882a
• Content: Azure Service Bus bindings for Azure Functions
• Content Source: articles/azure-functions/functions-bindings-service-bus.md
• Service: azure-functions
• GitHub Login: @craigshoemaker
• Microsoft Alias: cshoe

[PramodValavala-MSFT]

@timmyreilly Thanks for the question! We will review and get back to you!

[rajnemani]

A related question is if the batchSize property applicable to serviceBus and how it is related to maxConcurrentCalls if it is applicable.

[PramodValavala-MSFT]

@timmyreilly The service bus binding has an internal message pump which receives messages and processes them concurrently, up to the number of messages defined for maxConcurrentCalls per instance of the function app. So, once you function app starts scaling out, the number of concurrent messages being process would be - # of Instances X maxConcurrentCalls

Since you want this value to be ~300, you could set

• maxConcurrentCalls to 60 in host.json
• WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT to 5 in your app settings Note that this setting is still in preview and is unreliable if higher as mentioned in the docs.

But 60 could be a bit too much considering the 1.5GB RAM and 1 vCPU that consumption instances get if your processing is intensive, potentially killing the instance. You should reduce depending on your scenario.

@rajnemani The batchSize property has the same purpose but is for the Queue Storage binding instead.

[PramodValavala-MSFT]

@timmyreilly Just following up here... Hope my previous comment clears things up.

[timmyreilly]

Yeah, this is super helpful, I feel like this could be helpful in the documentation. And just to clarify, I can set the WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT to 5, 4, 3, 2, or 1? But not 6. What happens if I select 6, 7, 8, or 45? Also, what are the viable options for maxConcurrentCalls? Could I have:

• WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT to 1
• maxConcurrentCalls to 1

And expect a concurrent messages processed = 1?
or

• WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT to 1
• maxConcurrentCalls to 1000

And expect a concurrent messages processed = 1000

Thank you,
Tim

[PramodValavala-MSFT]

@timmyreilly I believe this section would be the best to place cover this. Feel free to open an issue on that doc to track.

Your expectations from the scenarios is accurate. But I wouldn't count on having 1000 messages being processed from a single function instance for the amount of RAM/CPU you get but it does depend on what kind of processing you are doing.

While there is no limitation for the app setting as such, the reliability is not guaranteed for values >5 due to the preview nature of the feature. There are plans to make this reliable.

[timmyreilly]

Thank you for the clarifications @PramodValavala-MSFT, I'm going to be doing some performance testing this week to see if I can confirm my understanding. I'll keep you updated!

[PramodValavala-MSFT]

@timmyreilly Glad we could help! Feel free to open an issue on the other doc which I believe would be a better place to cover this.

Since there is no doc update required here, we will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

[timmyreilly]

An early chart of the results of a couple permutations for those curious.