1
votes

We have a Linux Function App which consumes messages from Azure Service Bus using a ServiceBusTrigger.

When a message is added to a subscription on ASB, it takes a full minute for the function app to start up in response. Once warm all subsequent messages are consumed very quickly, but surely a cold start does not explain a minute's delay?

2/3/2021, 8:45:22.936 AM | MyApi.DataAccess.ServiceBus.ServiceBusClient | West Europe | Successfully published message to AzureServiceBus
2/3/2021, 8:46:24.000 AM | Host.Startup |   | Loading functions metadata

I can replicate this again and again consistently, the delay is almost exactly a minute always, and only happens when the function is cold. Again cold starts are understandable, but the delay in this case is huge - there must be something else going on. A few things to note:

  • We are using the Linux Consumption Plan (tried Windows but saw huge delays also)
  • We are using Azure Service Bus SessionIds
  • We are using functions V3
  • There are 9 consumer functions as part of the function app
  • In Azure Portal the function app shows as having no functions in the Functions section (this might just be expected for Linux, as the UI also says "Editing functions in the Azure portal is not supported for Linux Consumption Function Apps.")

Here's what the signature of one our consumer functions looks like:

[FunctionName("MyEventHandler")]
public async Task Run([ServiceBusTrigger("MyEvent",
        Consts.ServiceBus.SubscriptionName,
        Connection = "ServiceBusConnectionString",
        IsSessionsEnabled = true)]
    MyMessage message,
    ILogger log)

What would be nice is if we could see when the function first realises there's a message on the subscription, or how often it's polling the subscription. Is this available anywhere?

1
Anything to do with Scheduled messages by any chance? I won't put 1 minute past Azure Functions' startup time, but consistently? probably not. Is the situation same even when you send lots of messages? - Kashyap
In this case it seems to be consistently around 60-61 seconds, but it can't be message scheduling because once warmed, the consumption is almost immediate. You might just put it down to cold starts, but surely there's no way a small function app (let alone a Linux function app) can take that long? - FBryant87

1 Answers

1
votes

I observed way longer "cold start" durations in the past for service bus triggers. My assumption was always that it is not really a "cold start" after all. There is no explicit HTTP call which wakes up your function. Instead, your function goes to sleep completely and still needs to trigger for new messages.

My theory is: If you don't receive messages in your queue for a while, the process which watches your service bus will go to sleep as well, and only wake up by itself periodially. This is probably the minute you are observing.

Interestingly enough, while I always considered this as "this makes sense", there is little to no actual information about this. So I don't have a source other than my own experience. So there is the possibility that it should work way faster and I have the same issue in my apps as you describe.

https://mikhail.io/2019/03/reducing-azure-functions-cold-start-time/

https://markheath.net/post/avoiding-azure-functions-cold-starts