【问题标题】:gremlin.net with Cosmos DB: RequestRateTooLargegremlin.net 与 Cosmos DB:RequestRateTooLarge
【发布时间】:2018-03-30 13:46:48
【问题描述】:

在执行涉及大约 60 个顶点的查询时,我得到 RequestRateTooLarge 异常。该问题似乎与查询中涉及的顶点和边的数量有关(“较小”的查询不会发生这种情况)。增加吞吐量并不能解决问题,只是发生频率降低了。

在检索查询结果之间等待一段时间是否有用? IE。在对 Graph API 的 query.ExecuteNextAsync() 之类的调用之间执行 Thread.Sleep()。我在 gremlin.net 中找不到等价物,所以我还没有尝试过。

如果这不是解决方案,我该怎么办?

【问题讨论】:

  • 感谢您的回复。关于我表达得很糟糕的吞吐量,我的意思是我试图将它保持在尽可能低的水平,但是仅仅增加它似乎并不是解决问题的一般解决方案,它只会降低它发生的频率。 Cosmos documentation 说 RequestRateTooLarge 响应有一个标头 x-ms-retry-after-ms 告诉在下一个请求之前等待多长时间,但是我如何从异常中获取这个值?
  • 这是个例外:pastebin.com/2QN9tHNQ。它的 InnerException 为 null。

标签: azure-cosmosdb graph-databases gremlin


【解决方案1】:

引入等待期将解决您遇到的 RequestRateTooLarge 异常。

另一种选择是增加容器的预留吞吐量。您可以找到有关超出预留吞吐量异常here 的更多信息。

【讨论】:

  • 任意等待时间不会有帮助,因为总是存在 RU 不足会将下一个查询推到等待之外的情况。并且 OP 已经声明 400RU 限制是项目要求(尽管这并没有多大意义)。
  • 同意!最好的办法是做出相应的计划。 Azure Cosmos DB 容量规划工具:documentdb.com/capacityplanner
猜你喜欢
  • 2018-08-06
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-09-24
  • 1970-01-01
  • 1970-01-01
  • 2020-08-31
  • 2021-11-14
相关资源
最近更新 更多