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 订阅的所有事件。我的主要目标是处理有关虚拟机的 startstop 操作的事件,然后在收到这些事件时执行某些操作。

但是,我注意到事件中记录的 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 日志门户页面中看到。