dotnet-isolated ServiceBusTrigger very slow with IsSessionsEnabled

Question

Hello,

I am seeing very slow ServiceBusTrigger trigger behavior for queues that are session enabled. It looks like a 'batch' amount of messages are being read from the queue, and the function called. However after the initial calls, nothing then happens until about 60s then another 'batch' amount are being called. The messages are being processed, just at a rate of about 10 per 60s.

I can reproduce this locally and deployed in an Azure function. This behavior doesn't happen when not using .net6/isolated functions. And also doesn't happen for non-session-enabled queues.

The code looks like this:

    [Function("DotNetIsolatedSessionsIssueTestQueue")]
    public async Task DotNetIsolatedSessionsIssueTestQueue(
        [ServiceBusTrigger("test1", Connection = "ServiceBusConnection", IsSessionsEnabled = true)] byte[] message,
        FunctionContext context)
    {
        await Task.CompletedTask;
    }

Is this a known problem? Any ideas on how to fix it?

There is nothing wild in my host.json file:
{
"version": "2.0"
}

Nor the local.settings.json:
{
"IsEncrypted": false,
"Values": {
"FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
"FUNCTIONS_EXTENSION_VERSION": "~4",
"AzureWebJobsStorage": "UseDevelopmentStorage=true",
"ServiceBusConnection": "Endpoint=xx;SharedAccessKeyName=ServicesKey;SharedAccessKey=***",
}
}

Answer 1

@Paul Coleman ,

Welcome to Q&A and thanks for posting your query here.

First I would suggest you to make sure that the "Always On" option (available in configuration blade) is turned on so that cold starts are avoided. Please note that, this is applicable only for function apps running on dedicated app service plan and elastic premium sku.

Concurrency and batching is where performance can be improved from Functions platform perspective. It is upto you configure the number of messages that needs to be processed in a batch and you can have upto 16 concurrent sessions under the sessionhandler options. We can add sessionhandleroptions under the host.json file

"sessionHandlerOptions": {
"autoComplete": false,
"messageWaitTimeout": "00:00:30",
"maxAutoRenewDuration": "00:55:00",
"maxConcurrentSessions": 16
}
Host.json reference : https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-service-bus#hostjson-settings

Please try this configuration and let me know the outcome.

I hope this helps!

Please 'Accept as answer' and ‘Upvote’ if it helped so that it can help others in the community looking for help on similar topics.

Answer 2

It appears with version 5.x of the service bus SDK things changed:

"The previous illustration shows three concurrent session receivers. One Session with SessionId = 4 has no active, owning client, which means that no messages are delivered from this specific session. A session acts in many ways like a sub queue."

https://learn.microsoft.com/en-us/azure/service-bus-messaging/message-sessions#session-features

The default current streams is 8 apparently. So once my 8 streams have been 'used' by 8 unique session ids, the streams sit waiting for sessionIdleTimeout to look for a different session id to pick up.

This behavior I'm seeing is by (new) design then. To change sessionIdleTimeout you can do something like this in your hosts.json file:
{ "version": "2.0", "extensions": { "serviceBus": { "sessionIdleTimeout": "00:00:20" } } }