Hi @Marwen TALEB 

Thank you for reaching out. Is this specific to a particular API call, like time series, sequence etc.?
​​​​@Jason Dressel @Glen Sykes 

Thanks
 

@Marwen TALEB 

According to the Cognite documentation, it is recommended to use a reasonable number of parallel retrieval partitions, typically up to 10. Exceeding this limit might be causing the issue you're experiencing.

To handle HTTP response codes like 429 (Too Many Requests), Cognite suggests implementing a retry strategy based on truncated exponential backoff. This approach allows the system to automatically retry the request after a progressively longer wait time, preventing overwhelming the server.

Example of Truncated Exponential Backoff:

In a truncated exponential backoff strategy, the wait time between retries increases exponentially, but with a cap to avoid excessive delays. Here’s how it might work:

• The initial retry happens after a base wait time, for example, 1 second.
• For each subsequent retry, the wait time is doubled (e.g., 1s, 2s, 4s, 8s).
• However, the backoff is truncated, meaning it will not exceed a maximum limit (e.g., 32 seconds).
• This process is repeated for a set number of retries (e.g., up to 5 or 6 retries).

This method helps in efficiently handling temporary server overloads while maintaining system performance.

Hope this helps!
If you end up exploring a different approach, please share it with the community.

Cheers,
André

Hi Marwen,

Great answer from @Andre Alves here, thank you!

As Isha asks, it would be useful to understand which APIs in particular you’re asking about, but in general the answer is we believe that our current limits are reasonable and provide great performance under normal circumstances and when leveraged fully using techniques such as parallelisation.

When we have previously encountered customers that require higher levels of throughput, we have most often found that there are query patterns being used with high potential for optimisation.  This often would involve reviewing the underlying data model as well as the query logic itself.

If you could let us know which APIs you are using we can try to help further.

Kind Regards, Glen

Hello, 

Our use case is that we are a data middleware build on top of Cognite.

We are consumed by several consumer applications. Each application has one to many backends (horizontal scaling) using the same application client id.  These applications consume data models mainly via Graphql API.

Some application might expect some days of very high loads. 

It is difficult for me to give you a very precise use case of these high loads and the queries that they are making because these applications did not plug to our data layer yet.

My request was more to know if it is something that can be increased if the right use case shows up.

Cheers, 
Marwen

As a general principle we’re very open to collaborating on such matters and our preferred mode is to have early exposure to your architectural thinking so as to guide you on how best to make use of our APIs both in terms of features and limitations.  

If we arrive at a point in future where you hit capacity limits, having collaborated with us, we would absolutely review our implementation and look at how we can improve performance.

When it becomes problematic for us is where partners start out with an architecture that would inherently be problematic for the way our APIs function and then have to respond with disappointing answers (I’m not implying you are doing this by the way!).  We seek to avoid those types of discussion where at all possible!  Working closely with your appointed Cognite Solution Architect or TAM would be my recommendation.

I hope this is useful, and I hope your development with CDF is fun and productive!