"Wake up" 服务总线队列触发 Azure 函数的时间
"Wake up" time of Azure Function triggered by Service Bus Queue
我有一个由 Azure 服务总线队列触发的 Azure 函数 - Azure 函数应用托管在消费计划中。
当队列中出现新消息时,唤醒 Azure Function 最多需要多长时间? (假设过去 20 分钟内没有消息)。
是否在任何地方指定?我在 Documentation 中发现:
For non-HTTP triggers, new instances will only be allocated at most once every 30 seconds.
这是否意味着我无法在 30 秒内更快地处理队列中的第一条消息?
将 Timer Triggered Azure Function 添加到同一个 Function App(连同 Service Bus triggered)是否有助于保持 Azure Function 实例正常运行和 运行?
Azure Functions 可以 运行 消费计划或专用应用服务计划。
如果您运行处于专用模式,则需要将函数应用程序的Always On
设置正确打开为运行。 Function 运行time 会在几分钟不活动后进入空闲状态,因此只有 HTTP 触发器会实际“wake up
”您的函数。这类似于 WebJobs
必须启用 Always On 的方式。
有关详细信息,请参阅 Azure Functions 文档中的 Always On。
函数应用程序的超时持续时间由 host.json 项目文件中的 functionTimeout 属性 定义。以下 table 显示了两个计划和两个 运行 时间版本的默认值和最大值(以分钟为单位):
您可以在此处阅读有关冷启动的更多信息。
https://azure.microsoft.com/en-in/blog/understanding-serverless-cold-start/
HTTP 触发器肯定会帮助您预热您的实例,但满足 24/7 类型要求的理想方法是使用专用的 App Serice 计划。希望对你有帮助。
首先,使用消费计划,闲置20分钟左右,函数应用进入闲置状态。然后如果你使用该功能,你会遇到cold start,需要一些时间才能唤醒。
针对您的问题:
Does it mean that I won't be able to process the first message in the
queue faster than within 30 seconds?
取决于以下(link是here):
1.which language you're using (eg. function using c# is more faster than java), 以下内容摘自link 以上:
典型的冷启动延迟时间为 2 到 15 秒。 C# 函数通常在 3 秒内完成启动,而 JavaScript 和 Java 的尾部更长。
2.The 函数中的依赖项数:
添加依赖项并因此增加部署包的大小将进一步增加冷启动持续时间。
will adding Timer Triggered Azure Function to the same Function App
(along with Service Bus triggered) help to keep the Azure Function
instance up and running ?
是的,将定时器触发的 azure 函数添加到相同的函数应用程序将使其他函数保持热身(热身和 运行)。
处理 ServiceBusTrigger 函数的 "cold start" 的另一个选项是使用 Azure 事件网格 的事件功能,如果服务总线实体中没有消息并且有新消息到达,则立即发出事件。查看更多详细信息 here。
请注意,当第一条消息到达服务总线实体时,事件会立即发出。在这种情况下,当消息存在时,下一个事件将根据 listener/receiver 的空闲时间发出。这个空闲(看门狗)时间是从上次在服务总线实体上使用 listener/receiver 开始的 120 秒周期性的。
这是一个推送模型,服务总线实体上没有侦听器,因此 AEG 订阅者(EventGridTrigger 函数)将 "balanced" 使用 ServiceBusTrigger 函数(它的 listener/receiver)接收消息。
使用REST API for deleting/receiving来自服务总线实体(队列)的消息,订阅者可以非常简单直接地获取它。
因此,在主题 providers/Microsoft.ServiceBus/namespaces/myNamespace 上使用 AEG 事件并在 eventType = [=39= 上进行过滤],可以通过ServiceBudTrigger函数并行接收消息,解决"cold start".
上的AF问题
请注意,只有 Azure 服务总线高级层集成到 AEG。
以下代码片段显示了使用 EventGridTrigger 函数的 AEG 服务总线订阅者示例:
#r "Newtonsoft.Json"
using System;
using System.Threading.Tasks;
using System.Text;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Web;
using Newtonsoft.Json;
using Newtonsoft.Json.Linq;
public static async Task Run(JObject eventGridEvent, ILogger log)
{
log.LogInformation(eventGridEvent.ToString());
string requestUri = $"{eventGridEvent["data"]?["requestUri"]?.Value<string>()}";
if(!string.IsNullOrEmpty(requestUri))
{
using (var client = new HttpClient())
{
client.DefaultRequestHeaders.Add("Authorization", Environment.GetEnvironmentVariable("AzureServiceBus_token"));
var response = await client.DeleteAsync(requestUri);
// status & headers
log.LogInformation(response.ToString());
// message body
log.LogInformation(await response.Content.ReadAsStringAsync());
}
}
await Task.CompletedTask;
}
我有一个由 Azure 服务总线队列触发的 Azure 函数 - Azure 函数应用托管在消费计划中。
当队列中出现新消息时,唤醒 Azure Function 最多需要多长时间? (假设过去 20 分钟内没有消息)。
是否在任何地方指定?我在 Documentation 中发现:
For non-HTTP triggers, new instances will only be allocated at most once every 30 seconds.
这是否意味着我无法在 30 秒内更快地处理队列中的第一条消息?
将 Timer Triggered Azure Function 添加到同一个 Function App(连同 Service Bus triggered)是否有助于保持 Azure Function 实例正常运行和 运行?
Azure Functions 可以 运行 消费计划或专用应用服务计划。
如果您运行处于专用模式,则需要将函数应用程序的Always On
设置正确打开为运行。 Function 运行time 会在几分钟不活动后进入空闲状态,因此只有 HTTP 触发器会实际“wake up
”您的函数。这类似于 WebJobs
必须启用 Always On 的方式。
有关详细信息,请参阅 Azure Functions 文档中的 Always On。
函数应用程序的超时持续时间由 host.json 项目文件中的 functionTimeout 属性 定义。以下 table 显示了两个计划和两个 运行 时间版本的默认值和最大值(以分钟为单位):
您可以在此处阅读有关冷启动的更多信息。
https://azure.microsoft.com/en-in/blog/understanding-serverless-cold-start/
HTTP 触发器肯定会帮助您预热您的实例,但满足 24/7 类型要求的理想方法是使用专用的 App Serice 计划。希望对你有帮助。
首先,使用消费计划,闲置20分钟左右,函数应用进入闲置状态。然后如果你使用该功能,你会遇到cold start,需要一些时间才能唤醒。
针对您的问题:
Does it mean that I won't be able to process the first message in the queue faster than within 30 seconds?
取决于以下(link是here):
1.which language you're using (eg. function using c# is more faster than java), 以下内容摘自link 以上:
典型的冷启动延迟时间为 2 到 15 秒。 C# 函数通常在 3 秒内完成启动,而 JavaScript 和 Java 的尾部更长。
2.The 函数中的依赖项数:
添加依赖项并因此增加部署包的大小将进一步增加冷启动持续时间。
will adding Timer Triggered Azure Function to the same Function App (along with Service Bus triggered) help to keep the Azure Function instance up and running ?
是的,将定时器触发的 azure 函数添加到相同的函数应用程序将使其他函数保持热身(热身和 运行)。
处理 ServiceBusTrigger 函数的 "cold start" 的另一个选项是使用 Azure 事件网格 的事件功能,如果服务总线实体中没有消息并且有新消息到达,则立即发出事件。查看更多详细信息 here。
请注意,当第一条消息到达服务总线实体时,事件会立即发出。在这种情况下,当消息存在时,下一个事件将根据 listener/receiver 的空闲时间发出。这个空闲(看门狗)时间是从上次在服务总线实体上使用 listener/receiver 开始的 120 秒周期性的。
这是一个推送模型,服务总线实体上没有侦听器,因此 AEG 订阅者(EventGridTrigger 函数)将 "balanced" 使用 ServiceBusTrigger 函数(它的 listener/receiver)接收消息。
使用REST API for deleting/receiving来自服务总线实体(队列)的消息,订阅者可以非常简单直接地获取它。
因此,在主题 providers/Microsoft.ServiceBus/namespaces/myNamespace 上使用 AEG 事件并在 eventType = [=39= 上进行过滤],可以通过ServiceBudTrigger函数并行接收消息,解决"cold start".
上的AF问题请注意,只有 Azure 服务总线高级层集成到 AEG。
以下代码片段显示了使用 EventGridTrigger 函数的 AEG 服务总线订阅者示例:
#r "Newtonsoft.Json"
using System;
using System.Threading.Tasks;
using System.Text;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Web;
using Newtonsoft.Json;
using Newtonsoft.Json.Linq;
public static async Task Run(JObject eventGridEvent, ILogger log)
{
log.LogInformation(eventGridEvent.ToString());
string requestUri = $"{eventGridEvent["data"]?["requestUri"]?.Value<string>()}";
if(!string.IsNullOrEmpty(requestUri))
{
using (var client = new HttpClient())
{
client.DefaultRequestHeaders.Add("Authorization", Environment.GetEnvironmentVariable("AzureServiceBus_token"));
var response = await client.DeleteAsync(requestUri);
// status & headers
log.LogInformation(response.ToString());
// message body
log.LogInformation(await response.Content.ReadAsStringAsync());
}
}
await Task.CompletedTask;
}