消费计划上的 Azure Function 冷启动最长可达 30 分钟
Azure Function on consumption plan cold start can be up to 30 minutes
我有一个 azure 函数 v3，使用 class 库方法用 C# 编写。
- 函数由blob存储触发
- 函数正在使用消费计划。
问题是冷启动可以长达30分钟！我查阅了 this link
的文档
但是没有关于预期冷启动时间的具体数字。
一个有趣的观察是，如果我导航到门户并点击刷新按钮：
然后函数立即被触发。
- 这是正常的、预期的行为吗？
- 能否请您指点我任何文档，明确说明 ~0-30-50 分钟对于消费计划的冷启动是可以的？
不，这不正常。冷启动时间不应太长。 Here 是最近的性能测试，应该会给你答案。
消费计划就是azure所说的“无服务器”模式；这是什么意思-
your code reacts to events, effectively scales out to meet whatever load you’re seeing, scales down when code isn’t running, and you’re billed only for what you use.
冷启动只不过是
phenomenon that applications which haven’t been used take longer to start up.
当您使用消费计划时，Azure Functions 主机的实例会根据传入事件的数量动态添加和删除。
如果您在消耗计划上编写和部署了“重量级”代码，这需要大量内存和资源才能加载执行，则可能需要更多时间，例如您的情况。
当您从门户点击刷新按钮时 - Functions 运行时将重置，并且任何所需的扩展都会加载到 worker 上并加载到内存中。这就是它减少大部分延迟的原因。
要了解有关 azure 无服务器模型中的冷启动以及如何最小化冷启动的更多信息，请参阅此处 - Understanding serverless cold start
减少更多；您可以有一个预热请求，该请求将根据时间间隔命中，并且您的函数将始终加载到内存中。
一般来说，冷启动发生在您的函数在 ~20 分钟内 运行
为避免这种情况，如果您 运行 您的代码足够频繁以使其保持热状态，则不会发生冷启动（除非您横向扩展）
一个常用的方法是制作一个简单的“调用者”辅助函数，它每隔 5/10 minutes
调用一次你的函数
如果这不适合您的解决方案，并且您可以多付一点钱，您可以 运行 专用计划中的功能。
“Unavailable Executions” is the total number of executions within
Total Triggered Executions which failed to run. An execution failed to
run when the given Function App history log did not capture any output
five (5) minutes after the trigger is successfully fired.
这是不正确的，您指的是超时持续时间 - 这不等同于冷启动。如果您的函数需要那么长时间，它的原因是 exception/error （我不是说代码中的异常）。在任何文档（即使是微软的文档）中都没有说冷启动需要 30 分钟。
如果冷启动时间过长（>~1 分钟）并且您确定没有任何启动错误 - 分解您的函数并并行触发这些函数（如果可能）。 Application Insights 是您的朋友。
最后，没有确切的数字 - 这是基于每次使用的数据。有很多因素会影响执行时间——这可能会导致人们将责任归咎于冷启动，而不是函数的职责和依赖性。使用 Functions/Lambda，它不仅仅是“代码与任何其他 API 一样”，还有一些架构变化。
我绝对想知道的是，如果将代码作为代码发布到 Azure Function 与 docker (https://docs.microsoft.com/en-us/azure/devops/pipelines/targets/function-app-container?view=azure-devops&tabs=yaml) 相比，性能差异（尤其是冷启动）。我会找时间对此进行良好的实验并报告（不承诺）。
进一步阅读 -
- 粗略的冷启动时序研究：https://mikhail.io/serverless/coldstarts/azure/（他用 AWS Lambda 进行了相同的实验）
- Lambda 和函数的另一个很好的比较研究：https://azurefromthetrenches.com/comparative-performance-of-azure-functions-and-aws-lambda/
- https://azure.microsoft.com/en-in/blog/understanding-serverless-cold-start/
编辑：
虽然这有点旧 Github 问题线程，但该线程上报告的最长冷启动时间约为 2 分钟；似乎平均值在 20 多岁左右。请注意，当时 Microsoft Azure 的工程经理 (David Ebbo) 提到，琐碎的功能不应超过 10 秒。
https://github.com/Azure/azure-functions-host/issues/838
编辑 2：30 分钟的超时时间适用于非消费计划（消费计划为 5 分钟），所以我假设您打算使用非消费计划，在这种情况下您不会有冷启动问题。其他计划使功能保持温暖。
请仔细阅读您链接的文档中的“计划概述”- https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale#overview-of-plans
我有一个 azure 函数 v3，使用 class 库方法用 C# 编写。
- 函数由blob存储触发
- 函数正在使用消费计划。
问题是冷启动可以长达30分钟！我查阅了 this link
的文档但是没有关于预期冷启动时间的具体数字。
一个有趣的观察是，如果我导航到门户并点击刷新按钮：
然后函数立即被触发。
- 这是正常的、预期的行为吗？
- 能否请您指点我任何文档，明确说明 ~0-30-50 分钟对于消费计划的冷启动是可以的？
不，这不正常。冷启动时间不应太长。 Here 是最近的性能测试，应该会给你答案。
消费计划就是azure所说的“无服务器”模式；这是什么意思-
your code reacts to events, effectively scales out to meet whatever load you’re seeing, scales down when code isn’t running, and you’re billed only for what you use.
冷启动只不过是
phenomenon that applications which haven’t been used take longer to start up.
当您使用消费计划时，Azure Functions 主机的实例会根据传入事件的数量动态添加和删除。
如果您在消耗计划上编写和部署了“重量级”代码，这需要大量内存和资源才能加载执行，则可能需要更多时间，例如您的情况。 当您从门户点击刷新按钮时 - Functions 运行时将重置，并且任何所需的扩展都会加载到 worker 上并加载到内存中。这就是它减少大部分延迟的原因。
要了解有关 azure 无服务器模型中的冷启动以及如何最小化冷启动的更多信息，请参阅此处 - Understanding serverless cold start
减少更多；您可以有一个预热请求，该请求将根据时间间隔命中，并且您的函数将始终加载到内存中。
一般来说，冷启动发生在您的函数在 ~20 分钟内 运行
为避免这种情况，如果您 运行 您的代码足够频繁以使其保持热状态，则不会发生冷启动（除非您横向扩展）
一个常用的方法是制作一个简单的“调用者”辅助函数，它每隔 5/10 minutes
如果这不适合您的解决方案，并且您可以多付一点钱，您可以 运行 专用计划中的功能。
“Unavailable Executions” is the total number of executions within Total Triggered Executions which failed to run. An execution failed to run when the given Function App history log did not capture any output five (5) minutes after the trigger is successfully fired.
这是不正确的，您指的是超时持续时间 - 这不等同于冷启动。如果您的函数需要那么长时间，它的原因是 exception/error （我不是说代码中的异常）。在任何文档（即使是微软的文档）中都没有说冷启动需要 30 分钟。
如果冷启动时间过长（>~1 分钟）并且您确定没有任何启动错误 - 分解您的函数并并行触发这些函数（如果可能）。 Application Insights 是您的朋友。
最后，没有确切的数字 - 这是基于每次使用的数据。有很多因素会影响执行时间——这可能会导致人们将责任归咎于冷启动，而不是函数的职责和依赖性。使用 Functions/Lambda，它不仅仅是“代码与任何其他 API 一样”，还有一些架构变化。
我绝对想知道的是，如果将代码作为代码发布到 Azure Function 与 docker (https://docs.microsoft.com/en-us/azure/devops/pipelines/targets/function-app-container?view=azure-devops&tabs=yaml) 相比，性能差异（尤其是冷启动）。我会找时间对此进行良好的实验并报告（不承诺）。
进一步阅读 -
- 粗略的冷启动时序研究：https://mikhail.io/serverless/coldstarts/azure/（他用 AWS Lambda 进行了相同的实验）
- Lambda 和函数的另一个很好的比较研究：https://azurefromthetrenches.com/comparative-performance-of-azure-functions-and-aws-lambda/
- https://azure.microsoft.com/en-in/blog/understanding-serverless-cold-start/
编辑： 虽然这有点旧 Github 问题线程，但该线程上报告的最长冷启动时间约为 2 分钟；似乎平均值在 20 多岁左右。请注意，当时 Microsoft Azure 的工程经理 (David Ebbo) 提到，琐碎的功能不应超过 10 秒。 https://github.com/Azure/azure-functions-host/issues/838
编辑 2：30 分钟的超时时间适用于非消费计划（消费计划为 5 分钟），所以我假设您打算使用非消费计划，在这种情况下您不会有冷启动问题。其他计划使功能保持温暖。 请仔细阅读您链接的文档中的“计划概述”- https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale#overview-of-plans