Azure函数-并行/并行函数执行和横向扩展 [英] Azure Functions - Parallel/Concurrent function execution and scale out

问题描述

我最近开始使用Azure Functions，并且(在阅读SO和Microsoft文档之后)在理解横向扩展和并行执行方面遇到了麻烦.

I've recently started working with Azure Functions and (after reading SO and Microsoft docs) have been having trouble understanding scale out and parallel execution.

我的情况是带有CRUD Azure Functions的功能应用程序-他们需要像REST API一样快速并发地做出反应.但是，在我自己的浏览器上测试并运行10个不同的选项卡时，这些选项卡似乎是连续/顺序完成的(一个接一个，最后一个选项卡等待很长时间).

My situation is a function app with CRUD Azure Functions - they need to react quickly and concurrently like a REST API. However, when testing on my own browser and running 10 different tabs, it seems the tabs finish consecutively/sequentially (one after the other, the last tab waiting a LONG time).

我想知道我是否丢失了某些东西，或者是否有一种方法允许使用某些其他Azure产品进行并行执行?

I was wondering if I am missing something, or if there is a way to allow for parallel execution using some other Azure product?

(我已经阅读了一些应用程序设置，并且可能使用了APIM或托管了这些功能，但是这些似乎并不是答案.)

(I've read into a few application settings and possibly using APIM or hosting the functions, but these didn't seem to be the answer.)

谢谢！

推荐答案

我认为除了支付更多费用(应用服务计划或高级计划)外，另一种选择是编写更多代码以节省一大笔钱.

Other than paying more (App Service plan or Premium plan), one other option is to write a little more code to save a bunch of money.

• 将新的查询参数?keepWarm = 1 添加到要保持温暖的REST API端点.如果是 keepWarm 调用，则此函数的实现将返回200.
• 添加计划的功能(计时器触发)，该功能每X秒唤醒一次，并调用/endpoint?keepWarm = 1

• Add a new query param ?keepWarm=1 to your REST API endpoint you want to keep warm. Implementation of this function would be to return 200 if it's a keepWarm call.
• Add a scheduled function (timer-trigger) that wakes up every X seconds, makes a call to /endpoint?keepWarm=1

将全部内容托管在消费计划中.

Host this whole thing in consumption plan.

即使在 X = 1秒的情况下，您最终也可能会比其他昂贵的计划(我认为是100美元以上)少花很多钱(5-20​​美元).

Even for X = 1 second, you'll probably end up paying a LOT less ($5-20) than other expensive plans ($100+ I think).

恕我直言，高级和专用计划是在您需要更多火力时，而不是在您要保持温暖的时候.实际上，使用消耗计划可以让您扩展到200个实例，而其他昂贵计划的上限是10到100.

IMHO Premium and Dedicated plans are when you need more fire-power, not when you want to keep things warm. In fact Consumption plan would let you scale to 200 instances whereas the limit for other pricey plans is 10 to 100.

使用昂贵的计划，您可以获得更多的火力，因此您可以执行更大的任务并花费很长时间:

With pricey plans you do get more fire-power so you can do bigger tasks and take as long as you like:

• 210-840 ACU
• 1.75-14GB RAM
• 无限执行时间限制(#)

($)无限执行时间限制:如果您的触发器是HTTP触发器(REST API)，则由于

($) unbounded execution time limit: If your trigger is HTTP Trigger (REST API) then this is useless due to load balancer limitation

如果使用HTTP触发器的功能未能在230秒内完成，则Azure负载均衡器将超时并返回HTTP 502错误.该功能将继续运行，但将无法返回HTTP响应.

If a function that uses the HTTP trigger doesn't complete within 230 seconds, the Azure Load Balancer will time out and return an HTTP 502 error. The function will continue running but will be unable to return an HTTP response.

---

按比例缩放单位:

这还不清楚.

如此处所述./p>

在消费和高级"计划中，Azure Functions通过添加"Functions"主机的其他实例来扩展CPU和内存资源.实例数取决于触发函数的事件数.

消费"计划中的每个Function主机实例仅限于1.5 GB内存和一个CPU.主机的实例是整个功能应用程序，这意味着功能应用程序内的所有功能共享一个实例内的资源并同时扩展.

• 清楚的是
  • 当AFR(Azure函数运行时)确定需要扩展(基于流量)时，它将产生新的Function Host，每个Host包含整个Function App及其所有Function.
  • 作为开发人员，您必须以一种将功能限制为功能宿主所提供资源的方式来创建功能.
  • 每个主机是否每个功能只有一个或多个实例.
  • 同一应用程序内的多个不同功能是否可以并行执行.如果是，则每个功能实现都需要与该应用程序中共存的其他功能共享主机资源.

  还可以通过我猜在这种情况下，每个语言工作者进程都将在同一主机中运行并共享资源.

  I guess in this case each language worker process would run within same host and would share resources.

  这篇关于Azure函数-并行/并行函数执行和横向扩展的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！