Skip to main content

What is the maximum number of concurrent requests allowed through the Geotab API from a single source?

nschainblatt-1755
Original Poster

We have a backend processor that aggregates data for a CSV report. This involves making many multiCall requests concurrently to speed up processing. However, we've encountered issues that we believe are caused by hitting the maximum concurrent request limit. We've found a value that seems to work reliably without errors, but we're wondering: what is the recommended or optimal value to use here? Note I am not referencing the rate limits, but the total number of connections a single source may have with the Geotab servers at one time.

Join the conversation

You need to be logged in to reply to this post and participate in the Geotab Community discussions.

Top Answers

EishiFUN
Geotabber

Hey @nschainblatt-1755​  just wanted to follow up on this with some insight from one of our developers: That's a tough one. It really depends on the size of the db and the size of the server, and then what other activity is going on at the same time. For example, if there is bunch of other integrations running at the same time and pulling a lot of data, that will have an impact on performance. There is no defined best practice, we usually would recommend building in error trapping / retry functionality (sounds like they have it already) and finding the sweet spot for their particular integration use case.

 

Feel free to let me know if you have any further questions and I will talk with them or pull them in here.

6 Replies

EishiFUN
Geotabber

Hey @nschainblatt-1755​ ,

 

Thank you for asking your question in our community. I am not 100% sure but I am asking our team to see what they say.

 

I will let you know what I hear as soon as I do.

 

Have a good one!

Eishi FUN

EishiFUN
Geotabber

Hey @nschainblatt-1755​ our team got back to me and this is what they said: They should start by reading this page on the SDK site: https://developers.geotab.com/myGeotab/guides/rateLimits

 

Each object also has their specific rate limits at the end of their reference page:sdkFor multicalls in particular, we find that you will get diminishing returns once you have more than 200 calls in a multicall.

 

Let us know if you have any other questions.

nschainblatt-1755
Original Poster

Thanks for the reply. However, rate limits don't appear to be the issue we're facing, we're not encountering any OverLimitExceptions, and we're already following best practices for rate limiting.

 

We have a backend processor that issues concurrent requests while respecting those limits (many workers issuing requests at the same time instead of waiting for one after the other, each worker will wait and handle any rate limit issues on their own). Despite this, we were receiving generic server errors. After reducing the number of concurrent connections to Geotab from 50 to 15, the system started running smoothly again.

 

Given this, we're reaching out to ask if there's a recommended maximum number of concurrent connections (or semaphore value) you advise for this type of usage, based on your best practices for this particular scenario.

EishiFUN
Geotabber

Hey @nschainblatt-1755​  just wanted to follow up on this with some insight from one of our developers: That's a tough one. It really depends on the size of the db and the size of the server, and then what other activity is going on at the same time. For example, if there is bunch of other integrations running at the same time and pulling a lot of data, that will have an impact on performance. There is no defined best practice, we usually would recommend building in error trapping / retry functionality (sounds like they have it already) and finding the sweet spot for their particular integration use case.

 

Feel free to let me know if you have any further questions and I will talk with them or pull them in here.

nschainblatt-1755
Original Poster

Yeah I figured this one would be hard to pin point to a exact number haha. We will introduce an automatic limit to lower or raise when necessary to reduce errors but still be as efficient as possible.

 

Thanks!

EishiFUN
Geotabber

No problem. And good luck! Let us know any other questions that come up and we will help the best we can.

Still have questions?