Function App Concurrency and Dynamic Scaling does not seem to work

[mystiqu]

I have a consumption based function app (.Net 6, running in 64-bit mode) that keeps getting the warning "Your app is not configured for dynamic scaling. Scaling could be limited. Click to learn more."

However, the thing is that dynamic scaling is enabled by having the following in the host.json file:

"concurrency": {
        "dynamicConcurrencyEnabled": true,
        "snapshotPersistenceEnabled": true
}

Something with scaling also seems off, not sure if it's related though. It's a simple servicebus trigger, and if I add 10k message on the queue, the maximum throughput I get is 10 messages / second. I should say that each messages take approx. 1.5s to process, but it's mostly idle/latency time due to other reasons.

The CPU is almost idle (avg cpu utilization is 7%) and most of the processing is done in the database (which peaks at 7%) Checking the logs I can see that it's the same host instance that processes everything, so it seems it's never scaling out.

The persisted concurrency settings states that e.g. ProcessTrackingEventMessagesSBTrigger could run 503 executions in parallell - but that never happens.

{
    "Timestamp": "2024-10-30T19:40:37.6565727Z",
    "NumberOfCores": 2,
    "FunctionSnapshots": {
        "Host.Functions.ProcessTrackingEventMessagesSBTrigger": {
            "Concurrency": 503
        },
        "Host.Functions.ProcessCanonicalEvents": {
            "Concurrency": 54
        },
        "Host.Functions.ProcessPersistMessagesSBTrigger": {
            "Concurrency": 134
        },
        "Host.Functions.ProcessLogMessagesSBTrigger": {
            "Concurrency": 202
        }
    }
}

I've run out of ideas of what might be wrong at the moment.

[mystiqu]

Here's an update after further testing ' Setup

• Upgraded to .Net 8 isolated and
• Created a new servicebus trigger which does some proper processing by calculating the first 10.000 primes
• Loaded a queue with 100.000 messages

Test summary

• The test took around 40 minutes and in the end it processed approx. 260 messages / second.
• The average duration was fairly stable around 1.6s / execution

Executions / minute

Average duration

Now, this looks good at at glance - but there are a few issues here:

Concurrency snapshop The concurrency snapshot was continuously updated during the test. However, it did not appear to show the truth since it in the end was still showing 2 cores and 1 execution in parallel

{
    "Timestamp": "2024-10-31T16:33:49.7608895Z",
    "NumberOfCores": 2,
    "FunctionSnapshots": {
        "Host.Functions.SBTriggerDemo": {
            "Concurrency": 1
        }
    }
}

Scaling time It scales out really slow, if we get a burst of 100k messages (happens from time to time), I don't want to have to wait almost an hour until the scaling reaches an acceptable state

My questions are:

1. Why is the persisted concurrency state not changed to more than 2 cores and 1 execution?
2. Why does it take such time for the scaling to reach an acceptable level
3. Is there any way the scaling can be sped up?

[liliankasem]

Hey @alrod, is this something you can help with?