当我学习如何在Cosmos DB中使用图形时，我发现了两个Microsoft教程:
当我使用相同的查询时，其执行方式有所不同。
使用Gremlin.Net，它可以立即执行。我经常(我会说70％的时间)收到
RequestRateTooLargeException。如果我理解正确，则表示我一直达到我选择开始时的400RU/s限制。但是，当查询通过时，它的速度是使用Microsoft.Azure.Graph的解决方案的两倍。实际上，使用Micorosft.Azure.Graph，我必须在循环中调用
ExecuteNextAsync，该循环一次返回一个结果。因此，问题是:
1°)应该使用哪种方法以获得更好的性能？
2°)如何知道查询的RU，以便对其进行微调？
3°)是否可以提高现有馆藏的吞吐量？
更新
在问题3中，我发现数据库的“数据资源管理器” Blade 中的图形具有“比例和设置”，可以在其中更新吞吐量。
更新2
问题2，使用第一种方法(Gremlin.Net)时，我们无法收取RU费用，但是Microsoft.Graph方法
ExecuteNextAsync返回带有字段FeedResponse的RequestCharge。 最佳答案
您通过Gremlin.NET与Microsoft.Azure.Graphs遇到RequestRateTooLarge异常(429状态代码)的原因可能是由于CosmosDB Gremlin服务器上的重试策略与DocumentClient的默认重试策略之间的差异。
here描述了与这些错误有关的DocumentClient的默认重试行为:
因此，Microsoft.Azure.Graphs可能会在内部处理并从服务器重试这些错误，并最终成功。这样做的好处是可以提高请求的可靠性，但会混淆请求速率错误，并会影响执行时间。
在CosmosDB Gremlin服务器上，此重试策略的配额大大减少了，因此RequestRateTooLargeException错误将尽快浮出水面。
要回答您的问题:
1.应该使用哪种方法以获得更好的性能？
通过Gremlin.NET使用CosmosDB Gremlin服务器有望获得更好的性能。 Microsoft.Azure.Graphs使用不同的请求处理方法，该方法涉及到服务器的更多往返行程，因此除了要部署到服务器上的大量发行内容之外，还会产生开销。
2.如何知道查询的RU，以便对其进行微调？
RU费用将作为属性包含在Gremlin服务器响应中。目前，Gremlin.NET尚无办法在响应中公开属性，但是正在讨论here对客户端驱动程序的更改。
在此期间，您将观察您的请求通过Azure CosmosDB帐户门户上的Metrics Blade 有多频繁遇到429个错误。这显示了给定集合的请求数量，超出容量的请求，存储配额等的汇总 View 。
3.是否可以增加现有馆藏的吞吐量？
如您所见，您可以通过门户网站增加现有集合的吞吐量。或者，可以通过Microsoft.Azure.Documents SDK以编程方式进行此操作。
最后，我的建议是围绕Gremlin.NET请求添加一个重试策略，以处理这些异常并匹配RequestRateTooLargeException消息。
当响应状态属性在Gremlin.NET上公开时，它们将包括:
关于azure-cosmosdb - Cosmos Db Graph-Gremlin.Net与Microsoft.Graph的性能和吞吐量，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/48993817/