Azure Functions EventHub触发器扩展作业函数实例

时间:2017-04-18 21:51:07

标签: azure azure-functions azure-eventhub

我有一个Azure函数,它具有EventHub触发器,具有消耗计划。在我的测试中,我使用几个批次向事件中心拍摄3000个事件。由于这3000个事件的时间几乎是300个事件的时间的10倍,我怀疑这个Azure功能没有扩展到多个虚拟机/实例。

为了验证这个假设,我使用了一个Guid静态变量,我初始化了一次并记录了函数的每次运行。所有3000次运行都记录了相同的Guid。

即使我在host.json中指定了以下配置,也会发生这种情况: " eventHub":{       " maxBatchSize":1,       " prefetchCount":10     }

逻辑是,这将限制单个实例中的并行处理,并且因此会启动多个实例,但同样仅记录1个Guid。

注意,这不是App Service中唯一的功能。这可能是问题吗?需要满足哪些条件才能在多个VM上启动Function?

修改: 我有32个分区和20个吞吐量单位。第一个问题是我使用的是SendBatchAsync,它没有对事件进行分区。甚至SendAsync也没有带来任何规模,就像它没有分区一样。所以我创建了分区的eventhub发件人,并在客户端应用程序中发送事件时进行了循环分区。

AzureFunction处理的事件数量增加,但仍然没有创建超过1个VM。 此外,每秒处理的事件数量在开始时要大得多(每个时刻约200个),并且在2000年事件之后或接近结束时,它们降至约5。这与系统的负载无关,因为在9000个事件中观察到相同的行为,其中在~5k事件之后发生了减速。

此Azure功能持续50-250毫秒,具体取决于负载。 它还通过Azure存储队列触发器将事件发送到另一个Azure功能。有趣的是,由Queue触发的那个函数都不会扩展到超过1个VM,并且在eventhub触发azure函数的缓慢之前,它在队列中有~1k个消息。 host.json中的队列设置是"队列":{       " maxPollingInterval":2000,       " visibilityTimeout" :" 00:00:10",       " batchSize":32,       " maxDequeueCount":5,       " newBatchThreshold":1     }

感谢。

1 个答案:

答案 0 :(得分:1)

这取决于几个因素:

  • 您的事件中心所具有的分区数以及您正在编写的事件是否正在分区中分发。 Azure Functions使用Event Processor Host来处理您的工作负载,在此模式下可以获得的最大规模是每个分区一个VM。
  • 您正在执行的每个事件工作负载。例如,如果您的功能只执行日志,那么在单个VM上可以在不到5秒的时间内处理这3000个事件。这不能保证将您的应用程序扩展到多个实例。

但是,如果您在多个分区中编写一批事件,需要花费几分钟时间来处理,并且您没有看到随着功能扩展而吞吐量加速,那么这可能表明某些内容无法正常工作值得进一步调查。

相关问题