Cosmos DB Graph：Gremlin.Net与Microsoft.Azure.Graph预览版性能吞吐量疑问

Let’s break down your questions clearly—first why the performance gap exists, then how to fix those frustrating RequestRateTooLargeException errors in Gremlin.Net.

Why Gremlin.Net is Faster (But Prone to Throttling) #

The performance split comes down to how each SDK interacts with Cosmos DB and their built-in handling of throttling:

• Minimal Overhead in Gremlin.Net: Gremlin.Net is the official Apache TinkerPop driver, communicating directly with Cosmos DB’s Gremlin endpoint via WebSocket or HTTP. It has almost no extra abstraction layers—serialization/deserialization is lean, and there’s no Azure-specific middleware adding latency. When a query succeeds, it’s as fast as possible because there’s no hidden logic slowing it down.

• Silent Retries in the Preview SDK: The old Microsoft.Azure.Graph preview SDK likely includes automatic retry logic out of the box. When it hits a throttling error, it quietly retries the query (waiting the recommended RetryAfter time) instead of throwing an exception. This makes it seem "stable" but adds significant latency—you’re paying for those retry waits, which is why successful queries take twice as long.

• SDK Maintenance Status: Microsoft.Azure.Graph is a deprecated preview tool; Microsoft now recommends using Gremlin.Net or the latest Azure Cosmos DB .NET SDK with Gremlin support. The old preview version hasn’t received performance optimizations, while Gremlin.Net is actively maintained and tuned for TinkerPop compatibility and Cosmos DB integration.

Fixing RequestRateTooLargeException in Gremlin.Net #

Throttling happens because you’re hitting your 400 RU/s limit, but there are practical ways to mitigate this without immediately raising your quota:

1. Add Exponential Backoff Retries #

Since Gremlin.Net doesn’t handle retries by default, implement a retry policy using a library like Polly. This will automatically retry throttled requests with the correct wait time (using the RetryAfter value from the exception):

using Polly;
using Polly.Retry;

// Define a retry policy with exponential backoff and jitter to avoid "thundering herd" issues
AsyncRetryPolicy retryPolicy = Policy
    .Handle<RequestRateTooLargeException>(ex => ex.RetryAfter.HasValue)
    .WaitAndRetryAsync(
        retryCount: 3,
        sleepDurationProvider: (retryAttempt, ex, context) => 
            ((RequestRateTooLargeException)ex).RetryAfter.Value + 
            TimeSpan.FromMilliseconds(new Random().Next(0, 1000)),
        onRetryAsync: (ex, timespan, retryCount, context) =>
        {
            Console.WriteLine($"Throttled! Retrying in {timespan.TotalSeconds}s (Attempt {retryCount})");
            return Task.CompletedTask;
        });

// Wrap your Gremlin queries with the policy
await retryPolicy.ExecuteAsync(async () =>
{
    var resultSet = await _gremlinClient.SubmitAsync<dynamic>("your-gremlin-query-here");
    // Process your results here
});

2. Optimize Your Gremlin Queries #

Most throttling issues stem from inefficient queries eating up too many RUs:

• Avoid full graph scans: Instead of g.V(), add filters using indexed properties (e.g., g.V().has("userId", "123")). Make sure you’ve created Cosmos DB indexes for the properties you’re filtering on.
• Limit result sets: Use limit() or range() to reduce the number of vertices/edges returned in a single query.
• Simplify traversals: Cut out unnecessary steps like repeated traversals of the same path, or avoid expensive operations like order() on large datasets without filters.

3. Adjust Cosmos DB RU Settings #

• Scale up RU/s: If your workload consistently exceeds 400 RU/s, you can manually increase the RU quota in the Azure portal (note this will increase costs).
• Enable Auto-Scale: For variable workloads, turn on auto-scale RU/s—Cosmos DB will automatically adjust the RU count between a minimum and maximum threshold based on traffic, preventing throttling during peaks without overpaying during lulls.

4. Tune Gremlin.Net Client Configuration #

• Update to the latest version: Newer releases of Gremlin.Net include bug fixes and performance improvements tailored for Cosmos DB compatibility.
• Adjust connection pool settings: Tweak the ConnectionPoolSettings in GremlinClient to match your workload—for example, increasing the maximum number of connections can help handle concurrent requests more efficiently.

5. Batch Requests Where Possible #

If you have multiple small queries, batch them into a single Gremlin script to reduce round-trips to Cosmos DB:

var batchScript = @"
    g.V().has('userId', '123').property('lastSeen', now());
    g.V().has('userId', '456').property('lastSeen', now());
";
await _gremlinClient.SubmitAsync<dynamic>(batchScript);

内容的提问来源于stack exchange，提问作者François