azure compute 将事件推送到 Azure EventGrid 时速度慢吗?有没有办法更快地获取事件?
Is azure compute slow in pushing events to Azure EventGrid? Is there a way to get events quicker?
我有一个运行时 v2
和语言 C#
使用 EventGridTrigger
的 azure 函数应用程序。该函数订阅了源自 azure 订阅的所有事件。我的主要目标是处理有关虚拟机的 start
和 stop
操作的事件,然后在收到这些事件时执行某些操作。
但是,我注意到事件中记录的 EventTime
与函数应用程序收到它的时间之间有大约 30 - 120 秒的延迟。我通过确保在触发事件之前重新启动应用程序来验证这不是 冷启动 问题。对我来说,这听起来更像是天蓝色的计算问题。
例如,我重新启动了我的应用程序。然后我在 Azure 门户中点击了虚拟机的 Start
按钮。一段时间后,当 vm 启动时,azure compute 会向事件网格发送一个事件,我的函数应用程序会接收到该事件,并只记录该事件以及事件时间。 (见下图)。
请注意,在事件时间 (12:44:05 AM) 和函数接收并记录事件时间 (12:45:52) 之间有大约 107 秒的延迟上午)。
为了更深入地挖掘,我尝试检查在推送自己的事件时是否看到类似的延迟。我创建了一个自定义主题,并为该主题订阅了另一个功能。然后我使用 Azure Cloud Shell 将事件推送到我的自定义主题。在这种情况下,我可以看到我的函数几乎立即收到了事件。 延迟小于1秒.
这表明 EventGrid 本身很快,但 Azure 计算(VM 基础设施)在推送事件方面很慢。例如,如果它使用 EventTime
t
创建了一个事件对象,但随后在 (t+t1)
时间发布了它,那么 EventGrid 当然无法对获得的 t1
延迟做任何事情在事件到达 EventGrid 之前引入。
我的理解(/推测)是否正确?有什么方法可以更快地收到通知(<10 秒延迟)?
我同意@SeanFeldman。我已经测试了不同位置的五个虚拟机和服务总线队列的 AEG 订户。
我已经使用了REST API for start and deallocate a virtual machine. For status of the VM has been used the REST Get Instance View请求。
结果如下:
启动 VM 的示例:
实例视图响应状态:
"statuses": [
{
"code": "ProvisioningState/succeeded",
"level": "Info",
"displayStatus": "Provisioning succeeded",
"time": "2019-08-10T11:18:15.8833099-07:00"
},
{
"code": "PowerState/running",
"level": "Info",
"displayStatus": "VM running"
}
]
有趣(可用)次数:
"time": "2019-08-10T11:18:15.8833099-07:00"
"eventTime": "2019-08-10T18:18:29.5645489Z",
EnqueuedTimeUtc: 8/10/2019 6:19:54 PM
以上时序显示,当虚拟机运行(时间)。 AEG 在~100 秒 后将事件消息推送到订阅者队列(EnqueuedTimeUtc)。
取消分配 VM 的示例:
实例视图响应状态:
"statuses": [
{
"code": "ProvisioningState/succeeded",
"level": "Info",
"displayStatus": "Provisioning succeeded",
"time": "2019-08-10T11:51:11.9832611-07:00"
},
{
"code": "PowerState/deallocated",
"level": "Info",
"displayStatus": "VM deallocated"
}
]
有趣(可用)次数:
"time": "2019-08-10T11:51:11.9832611-07:00"
"eventTime": "2019-08-10T18:51:24.7467938Z",
EnqueuedTimeUtc: 8/10/2019 6:52:58 PM
请注意,上述延迟也可以在 VM/Active 日志门户页面中看到。
我有一个运行时 v2
和语言 C#
使用 EventGridTrigger
的 azure 函数应用程序。该函数订阅了源自 azure 订阅的所有事件。我的主要目标是处理有关虚拟机的 start
和 stop
操作的事件,然后在收到这些事件时执行某些操作。
但是,我注意到事件中记录的 EventTime
与函数应用程序收到它的时间之间有大约 30 - 120 秒的延迟。我通过确保在触发事件之前重新启动应用程序来验证这不是 冷启动 问题。对我来说,这听起来更像是天蓝色的计算问题。
例如,我重新启动了我的应用程序。然后我在 Azure 门户中点击了虚拟机的 Start
按钮。一段时间后,当 vm 启动时,azure compute 会向事件网格发送一个事件,我的函数应用程序会接收到该事件,并只记录该事件以及事件时间。 (见下图)。
请注意,在事件时间 (12:44:05 AM) 和函数接收并记录事件时间 (12:45:52) 之间有大约 107 秒的延迟上午)。
为了更深入地挖掘,我尝试检查在推送自己的事件时是否看到类似的延迟。我创建了一个自定义主题,并为该主题订阅了另一个功能。然后我使用 Azure Cloud Shell 将事件推送到我的自定义主题。在这种情况下,我可以看到我的函数几乎立即收到了事件。 延迟小于1秒.
这表明 EventGrid 本身很快,但 Azure 计算(VM 基础设施)在推送事件方面很慢。例如,如果它使用 EventTime
t
创建了一个事件对象,但随后在 (t+t1)
时间发布了它,那么 EventGrid 当然无法对获得的 t1
延迟做任何事情在事件到达 EventGrid 之前引入。
我的理解(/推测)是否正确?有什么方法可以更快地收到通知(<10 秒延迟)?
我同意@SeanFeldman。我已经测试了不同位置的五个虚拟机和服务总线队列的 AEG 订户。
我已经使用了REST API for start and deallocate a virtual machine. For status of the VM has been used the REST Get Instance View请求。
结果如下:
启动 VM 的示例:
实例视图响应状态:
"statuses": [
{
"code": "ProvisioningState/succeeded",
"level": "Info",
"displayStatus": "Provisioning succeeded",
"time": "2019-08-10T11:18:15.8833099-07:00"
},
{
"code": "PowerState/running",
"level": "Info",
"displayStatus": "VM running"
}
]
有趣(可用)次数:
"time": "2019-08-10T11:18:15.8833099-07:00"
"eventTime": "2019-08-10T18:18:29.5645489Z",
EnqueuedTimeUtc: 8/10/2019 6:19:54 PM
以上时序显示,当虚拟机运行(时间)。 AEG 在~100 秒 后将事件消息推送到订阅者队列(EnqueuedTimeUtc)。
取消分配 VM 的示例:
实例视图响应状态:
"statuses": [
{
"code": "ProvisioningState/succeeded",
"level": "Info",
"displayStatus": "Provisioning succeeded",
"time": "2019-08-10T11:51:11.9832611-07:00"
},
{
"code": "PowerState/deallocated",
"level": "Info",
"displayStatus": "VM deallocated"
}
]
有趣(可用)次数:
"time": "2019-08-10T11:51:11.9832611-07:00"
"eventTime": "2019-08-10T18:51:24.7467938Z",
EnqueuedTimeUtc: 8/10/2019 6:52:58 PM
请注意,上述延迟也可以在 VM/Active 日志门户页面中看到。