Azure Functions EventHub 触发器缩放作业函数实例
Azure Functions EventHub trigger scale job function instances
我有一个带有 EventHub 触发器和消费计划的 Azure 函数。在我的测试中，我分几批将 3000 个事件发送到事件中心。由于这 3000 个事件的时间几乎是 300 个事件的时间的 10 倍，我怀疑这个 Azure 函数没有扩展到多个 VMs/instances.
为了验证这个假设，我使用了一个 Guid 静态变量，我初始化了一次并在函数的每个 运行 中登录。所有 3000 运行 记录了相同的 Guid。
即使我在 host.json 中指定以下配置，也会发生这种情况：
"eventHub"：{
"maxBatchSize": 1,
"prefetchCount": 10
}
从逻辑上讲，这会限制单个实例中的并行处理，因此会启动多个实例，但同样只会记录 1 个 Guid。
请注意，这不是应用服务中的唯一功能。这可能是问题所在吗？ Function在多台VM上启动需要满足什么条件？
编辑：
我有 32 个分区和 20 个吞吐量单位。第一个问题是我使用的是 SendBatchAsync，它不会对事件进行分区。甚至 SendAsync 也没有带来任何规模，就像它不是分区一样。因此，我创建了分区的 eventhub 发送器，并在客户端应用程序中发送事件时进行了循环分区。
这增加了 AzureFunction 处理的事件数量，但仍然没有创建超过 1 个 VM。
此外，开始时每秒处理的事件数量要大得多（每个时刻约 200 个），在 2000 个事件之后或接近尾声时，它们下降到约 5 个。这与系统负载无关，因为在 9000 个事件中观察到相同的行为，其中在 ~5k 个事件后发生减速。
此 Azure 函数持续 50-250 毫秒，具体取决于负载。
它还通过 Azure 存储队列触发器将事件发送到另一个 Azure 函数。有趣的是，队列触发器触发的函数都没有扩展到超过 1 个 VM，并且在 eventhub 触发 azure 函数的缓慢之前，它在开始时在队列中有 ~1k 条消息。 host.json 中的队列设置为 "queues"：{
"maxPollingInterval": 2000,
"visibilityTimeout"：“00:00:10”，
"batchSize": 32,
"maxDequeueCount": 5,
"newBatchThreshold": 1
}
谢谢。
这取决于几个因素：
- 您的事件中心的分区数以及您正在编写的事件是否分布在您的分区中。 Azure Functions 使用 Event Processor Host 来处理你的工作负载，在此模式下你可以获得的最大规模是每个分区一个 VM。
- 您正在执行的每个事件的工作量。例如，如果您的函数除了记录之外什么都不做，那么这 3000 个事件可以在单个 VM 上用不到 5 秒的时间处理。这不能保证将您的应用程序扩展到多个实例上。
但是，如果您正在跨多个分区编写一批事件，这总共需要几分钟的时间来处理，并且您没有看到吞吐量随着函数的扩展而加速，那么这可能表明某些地方无法正常工作并需要进一步调查。
我有一个带有 EventHub 触发器和消费计划的 Azure 函数。在我的测试中，我分几批将 3000 个事件发送到事件中心。由于这 3000 个事件的时间几乎是 300 个事件的时间的 10 倍，我怀疑这个 Azure 函数没有扩展到多个 VMs/instances.
为了验证这个假设，我使用了一个 Guid 静态变量，我初始化了一次并在函数的每个 运行 中登录。所有 3000 运行 记录了相同的 Guid。
即使我在 host.json 中指定以下配置，也会发生这种情况： "eventHub"：{ "maxBatchSize": 1, "prefetchCount": 10 }
从逻辑上讲，这会限制单个实例中的并行处理，因此会启动多个实例，但同样只会记录 1 个 Guid。
请注意，这不是应用服务中的唯一功能。这可能是问题所在吗？ Function在多台VM上启动需要满足什么条件？
编辑： 我有 32 个分区和 20 个吞吐量单位。第一个问题是我使用的是 SendBatchAsync，它不会对事件进行分区。甚至 SendAsync 也没有带来任何规模，就像它不是分区一样。因此，我创建了分区的 eventhub 发送器，并在客户端应用程序中发送事件时进行了循环分区。
这增加了 AzureFunction 处理的事件数量，但仍然没有创建超过 1 个 VM。 此外，开始时每秒处理的事件数量要大得多（每个时刻约 200 个），在 2000 个事件之后或接近尾声时，它们下降到约 5 个。这与系统负载无关，因为在 9000 个事件中观察到相同的行为，其中在 ~5k 个事件后发生减速。
此 Azure 函数持续 50-250 毫秒，具体取决于负载。 它还通过 Azure 存储队列触发器将事件发送到另一个 Azure 函数。有趣的是，队列触发器触发的函数都没有扩展到超过 1 个 VM，并且在 eventhub 触发 azure 函数的缓慢之前，它在开始时在队列中有 ~1k 条消息。 host.json 中的队列设置为 "queues"：{ "maxPollingInterval": 2000, "visibilityTimeout"：“00:00:10”， "batchSize": 32, "maxDequeueCount": 5, "newBatchThreshold": 1 }
谢谢。
这取决于几个因素：
- 您的事件中心的分区数以及您正在编写的事件是否分布在您的分区中。 Azure Functions 使用 Event Processor Host 来处理你的工作负载，在此模式下你可以获得的最大规模是每个分区一个 VM。
- 您正在执行的每个事件的工作量。例如，如果您的函数除了记录之外什么都不做，那么这 3000 个事件可以在单个 VM 上用不到 5 秒的时间处理。这不能保证将您的应用程序扩展到多个实例上。
但是，如果您正在跨多个分区编写一批事件，这总共需要几分钟的时间来处理，并且您没有看到吞吐量随着函数的扩展而加速，那么这可能表明某些地方无法正常工作并需要进一步调查。