Does C# sdk use api rate limiting natively?

Guidance
1

Thinking of switching over to c# implementation of the SDK, I see Polly as dependency, wanted to confirm whether or not the calls are using the api approved rate limiting settings, or would I still need to implement my own rate limiting?

2

By default, the c# sdk will retry requests to our API which receive an HTTP 429 response after a short delay. The ComboCurveV1Api constructor also accepts an “enableCheckRateLimit” parameter which will attempt to ensure that the rate limit has not been reached before issuing a request. If neither of these is sufficient for your needs we do provide the RetryPolicy and AsyncRetryPolicy static properties in the RetryConfiguration class where you can supply your own Polly retry policies. These policies will be applied to all requests.

1 Like
3

Thank you for providing this information, this sounds more than sufficient for our needs, thank you!

4

Hey there Jeff, replying on this same thread as I have a quick question.

I finished refactoring my full load job, but I am having varying results from my local runs vs server runs…

The main difference being, it seems my local machine stays within the alloted rate limit with no occurrences of 429 errors whatsoever, but my server instance seems to grab 429 errors.

Wondering why this may be, and what is the best course of action to handle this, I am using the C# sdk, with the built in rate limiting, as well as rate limit checks enabled.

handling the retry is awkward as the error occurs at a “GetWellV2” function scope, while I am handling those items in another function that is converting them to bson documents.

tried adding in a buffer between request, but not getting much help there.

5

I’m not sure if you have tried it yet, but our API supports retry logic using Policies from the Polly library. These Policies can be accessed through the RetryPolicy and AsyncRetryPolicy static properties on the RetryConfiguration class. These policies can be customized however your application needs. Here is a simple example of waiting and retrying a request which receives an HTTP 429 response:

                RetryConfiguration.RetryPolicy = Policy<IRestResponse>
                    .HandleResult(x => x.StatusCode == HttpStatusCode.TooManyRequests)
                    .WaitAndRetry(5,
                        _ => TimeSpan.FromMilliseconds(5000));

This snippet could be called whenever you instantiate your ComboCurveV1Api client and it should apply to all subsequent calls. This particular approach may not be the best for HTTP 429 errors, but the Polly library offers a lot of options and customization on how you handle your retry logic. You could implement some kind of exponential backoff in the WaitAndRetry that might be better for this issue.

As far as why you are seeing differences locally vs on your server, I don’t know that I can provide much insight there. The rate limits are tied to an API key, so it should not matter on our end what machine the requests are issued from.

Some questions you might look into:

  1. Do the machines have similar specs and network latency?
  2. Could the server just be processing that much faster than your local?
  3. For your server, is it a single box or are you running some kind of serverless architecture that could spin up multiple instances?
  4. Could it be running multiple requests in parallel?