GeoDB Cities
Verified
✓
By
Michael Mogley |
Updated 7 days ago |
Data
Popularity
9.9 / 10
Latency
69ms
Service Level
100%
Health Check
100%
Back to All Discussions
Response timing
bill-bbctUN-JNto
2 years ago
We are using your service for a Alexa based skill that has certain timing requirements. Most of the time, I am able to retrieve data in less than 0.5 seconds, however, occasionally it is significantly longer. Sometimes it will take up to eight seconds to respond. I am at the $10/mo. tier right now as our product is still in beta. We will probably move to a higher tier after the product is released and we have more users. I’m wondering if we are being throttled, or doing something wrong. Alexa has a hard timeout of eight seconds, so occasionally our Alexa skill fails if the response takes too long.
Join in the discussion - add comment below:
Login / Signup to post new comments
I found one major culprit for the intermittent high latencies and made relevant changes. I’ve also redeployed to a higher performant GCP cluster. Latencies should now be more consistent. Please let me know what you think.
Just an update on this. Rapid recently sent me some timing logs indicating that the delays do appear to be coming from my GCP cluster. The issue may be a networking/LB bottleneck as the backend instances are not even close to being loaded. I will be looking at how to optimize the cluster and possibly move to AWS. Will send out a general announcement once these latency issues are resolved. No promises on timeframe at this point.
If you absolutely require consistent rock-bottom latencies, going with the self-hosting option remains your best bet at this moment.
Those are the only options for accessing the service.
I am not making many requests per second as we are still in development, and have never received a 429. Is there any way to avoid the Rapid proxy other than running our own instance? Thank you.
Hi. I have seen these occasional latencies in the RapidAPI logs. They may be the result of something going on with the Rapid proxy, as I’ve never been able to observe coincident CPU/memory pressure on the backend service. Having said that, how many requests per second are you making? If you were being throttled, you should actually get back a 429 (Too Many Requests). I assume this is not the case. If it is, going to a higher plan would help.
Otherwise, if you absolutely require consistent low-latency responses, your best bet would be to sign up for the self-hosting plan (outside of Rapid). This would allow you to keep one (or multiple) GeoDB instances within your own infrastructure, bypassing Rapid entirely. Because you’d be going directly to the instance, you’d be avoiding the impact of other users as well as the overhead of the Rapid proxy. In addition, if you colocated it with Alexa, you’d have an even better time of it.
In the meantime, I did send a message just now to RapidAPI support referencing this thread. If they come back with anything useful, I’ll repost (or perhaps they’ll respond directly here).