我在azure上有一个文档数据库数据库。当我归档用户记录及其所有数据时，我发生了一个特别繁重的查询。
我参加了S1计划并且会得到一个例外，表明我达到了RU / s的限制。 S1计划有250个。
我决定切换到标准计划，让您设置RU / s并支付费用。
我将其设置为500 RU / s。
我做了同样的查询，回过头看了一下监控图。
当我做最新的查询测试时，它说我做了226个请求，10个被限制。
为什么？我把它设置为500 RU / s。顺便说一下，查询失败了。
答案 0 :(得分：5)
首先，请求！=请求单位，因此您的226个请求在某个时刻会导致在一秒钟内需要超过500个请求单位。
DocumentDb API将告诉您每个请求成本的RU数，因此您可以检查该客户端以找出导致问题的请求。根据我的经验，即使是简单的by-id请求通常也要花费至少几个RU。 您如何看待成本取决于您使用的客户端SDK。在我的代码中，我添加了一些内容来自动记录所有超过10个RU的请求，我知道并且可以采取行动。
门户网站中的监控工具也非常不足，我知道团队正在努力解决这个问题。您每隔五分钟只能看到总RU，但您可能会尝试在一秒钟内使用600个RU，而您无法在门户中看到它。
在您的情况下，您可能只有一个大型查询，其成本超过500 RU - 日志记录会告诉您。在这种情况下，请查看生成的SQL以查看原因，甚至可以在此处发布。
或者，它可能是在很短的时间窗口内发射大量小请求的累积效应。如果您正在响应一个用户操作执行226个请求（我不知道您是否），那么您可能想重新考虑您的设计：）
最后，您可以重试失败的请求。我不确定其他SDK，但.Net SDK在放弃之前会自动重试请求9次（这可能是229请求命中服务器的另一种解释）。 如果您选择的SDK没有重试，您可以自己轻松完成;服务器将返回一个特定的状态代码（我认为429但不太记得）以及重试之前等待多长时间的指令。
请检查查询并更新您的问题，以便我们进一步提供帮助。