我有一个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 }
感谢。
答案 0 :(得分:1)
这取决于几个因素:
但是,如果您在多个分区中编写一批事件,需要花费几分钟时间来处理,并且您没有看到随着功能扩展而吞吐量加速,那么这可能表明某些内容无法正常工作值得进一步调查。