时间戳

首页 > 解决方案 > Azure 消费者函数应用对消息的反应极其缓慢

azure - Azure 消费者函数应用对消息的反应极其缓慢

问题描述

我们有一个 Linux 函数应用程序，它使用 ServiceBusTrigger 使用来自 Azure 服务总线的消息。

将消息添加到 ASB 上的订阅时，函数应用需要一整分钟才能启动响应。一旦温暖，所有后续消息都会很快被消耗掉，但是冷启动肯定不能解释一分钟的延迟吗？

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

我可以一次又一次地重复这个，延迟几乎总是一分钟，并且只在函数冷时发生。再次冷启动是可以理解的，但在这种情况下延迟是巨大的 - 肯定有其他事情发生。需要注意的几点：

下面是我们的一个消费者函数的签名：

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

如果我们能看到函数何时第一次意识到订阅上有消息，或者它轮询订阅的频率，那就太好了。这在任何地方都可用吗？

标签： azureazure-functionsazureservicebusazure-servicebus-topics

解决方案

过去，我观察到服务总线触发器的“冷启动”持续时间更长。我的假设始终是它毕竟不是真正的“冷启动”。没有明确的 HTTP 调用可以唤醒您的函数。相反，您的函数完全进入睡眠状态，仍然需要触发新消息。

我的理论是：如果您在队列中一段时间​​没有收到消息，那么监视您的服务总线的进程也会进入睡眠状态，并且只会周期性地自行唤醒。这可能是您正在观察的那一刻。

有趣的是，虽然我一直认为这是“有道理的”，但几乎没有关于此的实际信息。所以除了我自己的经验，我没有其他来源。因此，它可能会更快地工作，并且我的应用程序中遇到了与您描述的相同的问题。

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

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

推荐阅读