在过去一周左右的时间里,我们一直在经历 504, Gateway Timeout
从 MS Graph API 获取电子邮件消息时出错。在此之前运行了一个多月,同一个应用程序没有遇到该错误,至少没有出现任何显着频率。
$top=100&$orderBy=lastModifiedDateTime desc&$filter=lastModifiedDateTime lt 2019-09-09T19:27:55Z and parentFolderId ne 'JunkEmail'
我的问题 - 我们可以做些什么来消除/显着降低从 MS Graph API 获得 504、Gateway Timeout 错误的可能性?
我怀疑,由于我们要的是没有文件夹过滤器的消息,因此我们可能会强调查询引擎。只是一种预感,如果有人真正了解 MS Graph API,我很想知道这是否可能。此外,任何有助于我们更好地了解幕后情况的信息都将不胜感激。
更新 1 (2019-09-13 15:44:00 EST) - 这是应用程序在 12 小时内(大约)发出的一组获取请求的可视化。粉色条是成功获取的次数,浅蓝色条是失败的请求(都是 504,Gateway Timeout 作为失败代码)。如您所见,当应用程序启动时,它会出现许多故障,这些故障最终会减少并消失。然后从凌晨 4 点 30 分到 9 点 30 分左右,出现了许多故障,最终消退。几乎所有故障都发生在为一个拥有非常大邮箱(> 220K 消息)的用户获取消息时。我意识到这是一个小数据集,如果有帮助,我很乐意生成一个运行更长时间的数据集。此外,有问题的应用程序正在我们的 Azure 租户上运行,作为 Azure Function 应用程序的一部分,位于“美国东部”位置。
更新 2,(2019 年 9 月 16 日,美国东部标准时间 09:32:00) - 我们在过去 3 天运行了系统,这是该应用程序在此期间发出的获取请求的可视化。蓝色条为成功抓取,粉色条为抓取失败(均以 504,Gateway Timeout 作为失败代码)。总结是除了第一个晚上 11PM - 2AM 的小窗口外,对于这个具有大邮箱的特定用户,没有任何请求成功。实际上,这意味着尽管有重试逻辑等,我们无法处理该用户的数据。
最佳答案
Microsoft Graph 有时会很慢,并且会throttle偶尔。
我建议您让 Graph SDK 完成艰苦的工作,以免您自己编写代码来处理这一切。
使用 Microsoft Graph 客户端库版本 1.17.0+,因为它引入了自动重试 504 错误。当它们发生时,它还会处理节流(代码 429)。
我想说的是,当您自己获得 504 或 429 或将此类责任委托(delegate)给 SDK 时,您可以重试
关于microsoft-graph-api - 从 MS Graph API 获取消息时出现错误 504,网关超时,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/57892255/