从 MS Graph API 获取消息时出现错误 504，网关超时答案

【问题标题】：Getting error 504, Gateway Timeout, while fetching messages from the MS Graph API从 MS Graph API 获取消息时出现错误 504，网关超时
【发布时间】：2019-09-11 15:19:17
【问题描述】：

在过去一周左右的时间里，我们在从 MS Graph API 获取电子邮件消息时遇到了504, Gateway Timeout 错误。在此之前运行了一个多月，同一个应用程序没有遇到该错误，至少没有出现任何显着频率。

我们正在使用 V1.0 的 MS Graph API
我们的查询相当简单：

$top=100&$orderBy=lastModifiedDateTime desc&$filter=lastModifiedDateTime lt 2019-09-09T19:27:55Z and parentFolderId ne 'JunkEmail'

我们会为拥有大量数据（> 100K 电子邮件）的用户获得超时，但偶尔会为数据量较小（大约 18K 电子邮件）的用户获得超时。从系统工作到现在我们看到很多超时，音量并没有太大变化。
我们已尝试简化查询、减少我们请求的消息数量等，但这似乎只产生有限且间歇性的影响。

我的问题 - 我们可以做些什么来消除/显着降低从 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 的小窗口外，对于这个具有大邮箱的特定用户，没有任何请求成功。实际上，这意味着尽管有重试逻辑等，我们无法处理该用户的数据。

【问题讨论】：

另一个值得注意的信息是超时发生在有时大约 30 秒，其余时间大约是 40 秒。
更新 - 我们一直在跟踪数据以查看我们何时以及多久收到 504、网关超时和一种模式开始出现。基本上，我们有时会看到邮箱中有超过 200K 条消息的用户的获取请求失败率为 50-100%。通常这些时期是我们第一次开始处理邮箱的时候，即在一段时间不活动之后。随着时间的推移，错误率开始下降，最终我们得到很长一段时间（小时）没有 504 错误。这是基于过去几天运行系统的结果，而不是基于大量数据。

标签： microsoft-graph-api microsoft-graph-mail

【解决方案1】：

Microsoft Graph 有时会很慢，偶尔会throttle。

我建议您让 Graph SDK 完成艰苦的工作，以免您自己编写代码来处理这一切。

使用 Microsoft Graph 客户端库版本 1.17.0+，因为它引入了对 504 错误进行自动重试。当它们发生时，它还会处理限制（代码 429）。

我想说的是，当您自己获得 504 或 429 或将此类责任委托给 SDK 时，您可以重试

【讨论】：

很高兴了解 1.17.0 版本中 504 的自动重试。这肯定会有所帮助，但需要明确的是，我们在这里不是在谈论节流。来自节流链接 - When throttling occurs, Microsoft Graph returns HTTP status code 429 (Too many requests), and the requests fail. 节流不会导致 504 错误。
感谢 Kalyan，不必处理限制和超时当然是一个巨大的积极因素。我担心的是，少数用户会重复超时（尽管没有限制，因为我们非常谨慎地使用 API），这阻碍了他们数据处理的进展。是否没有解决方案来防止或至少显着减少超时的发生？
@floatingfrisbee 没有任何关于如何减少超时的规定性指导。 Microsoft Graph 是位于许多其他服务之上的服务代理（这些服务又依赖于其他服务）。超时有很多来源。我们最好的选择是优雅地处理它们。您是否看到超时模式？
@MichaelMainer 感谢您的评论。我还没有注意到一个强大的模式，但已经用一些可能相关的信息更新了我的原始帖子。如果有帮助，很高兴为您提供更多信息。虽然我知道 Graph 服务本质上是分布式的，但如果我们的用户出现大量故障，这实际上阻止了在合理的时间段内处理他们的数据，我们确实需要一种策略来处理它。
继续...从好的方面来说，在重试逻辑和我们所做的一些其他调整之间，我们现在似乎处于一个好位置，但我担心当我们遇到更大的邮箱，可以提示秤。

【解决方案2】：

很高兴听到重试有帮助。我有几个选择可以尝试：

1) 更改您的查询并将订购责任转移给客户。 $orderBy=lastModifiedDateTime desc 和过滤器需要创建索引，这会增加邮箱的负载。对于这些大型邮箱，进行客户端排序可能会更好。

2) 使用delta query（使用您的过滤器）同步并获得增量更改。您将必须添加文件夹层次结构同步。您也许可以进行并行调用。我怀疑这会在初始同步后为您提供更好的性能。

【讨论】：

我可能说得太早了。在过去的三天里，我们运行了一个实例，并得到了一些非常令人失望的结果。如果可以的话，请看一下原帖，我已经对其进行了另一次更新，提供了更多信息。
回复：第 1 点，关于将订单转移给客户。我不清楚它是否具有相同的语义。我们感兴趣的是一次一批地在时间上倒退。因此，如果有 100K 条消息的最后修改日期早于，请说“2019-09-15 15:30:00”。我想获取其中最近的 100 个，处理它们，然后获取下一个最近的 100 个，依此类推。如何在客户端进行排序？或者您是说我们放宽了按新近顺序处理它们的要求（如果这确实有助于解决问题，这可能没问题）。
Re：第 2 点，关于使用 delta 令牌。我们最初是从这种方法开始的，但由于它需要对每个文件夹进行查询，所以我们放弃了它。它增加了代码的复杂性，我们肯定会去那里，这是我们唯一的选择。但是，我确实希望 Graph API 提供的邮件端点在大多数情况下都能正常工作。

【解决方案3】：

我遇到了同样的问题。尝试获取所有消息时出现 504 错误。经过彻底检查后，我认为在我们的案例中，问题出在草稿上。在某些情况下，他们会抛出错误。添加过滤器后 "isDraft eq false" 504 停止，我们收到所有消息。原来有些草稿坏了。它们不会出现在 OWA 或 Outlook 中，在我们的例子中，与查询混淆的那个存储在不存在的 parentFolderId 下，在我看来，这本身就是一个巨大的问题。

【讨论】：