Last week, we encountered downtime on our navigation servers. It seemed that because of the downtime, a huge spike in iOS navigation requests occurred. We saw 3000% increase of requests for example, where we expect 20k requests we got 500k. We were puzzled why that would be.
Found out that the navigation SDK is the culprit.
How it works:
The user drives on their route that was successfully calculated
The SDK tries to find a faster route by doing a routing call to our servers every 2 mins (and some other requirements)
After a while, the servers get downtime
The SDK tries to search for a faster route again, but that call fails
Because the call fails, the guard guard let route = route fails, and the lastLocationDate isn't set to nil
That means that every location update thereafter will try to search for a faster route by doing a routing call
???
Server-hosting: PROFIT! 💰
Spam
The fix
The fix is two-fold:
Always setting the lastLocationDate to nil when the call is done, even if it fails. This means that the user has to wait 2mins (and other requirements) before it tries again in case of failure. That is fine in my opinion
Only do one call at a time. When the server times out, it should wait for that before it retries.
Description
Last week, we encountered downtime on our navigation servers. It seemed that because of the downtime, a huge spike in iOS navigation requests occurred. We saw 3000% increase of requests for example, where we expect 20k requests we got 500k. We were puzzled why that would be.
Found out that the navigation SDK is the culprit.
How it works:
guard let route = route
fails, and thelastLocationDate
isn't set to nilThe fix
The fix is two-fold:
lastLocationDate
tonil
when the call is done, even if it fails. This means that the user has to wait 2mins (and other requirements) before it tries again in case of failure. That is fine in my opinionThis will reduce the spammy calls to our servers