Reputation: 81
We are using the .NET SDK to upload data to our azure search service(s). We already have the logic in place to automatically back down if we start getting HTTP 207 response, and even further once we get HTTP 503 responses.
The problem I see... is it all seems like a black box. I want to know how busy the search service is, so we don't further cause problems by not waiting long enough before retrying a particular upload of data. Can we get any sort of diagnostic information on the status of an azure search service, how busy it is, etc? Can we get any sort of diagnostic information that we can use when receiving 207 and 503 so we can automatically wait a # of seconds or minutes (dynamically figured out based on how busy the search service reports it is), so we can most efficiently start sending more data when the search service is truly ready?
Thanks, Andres
Upvotes: 0
Views: 143
Reputation: 8634
Since you're using the .NET SDK, you already have retry behavior on 503s. The SDK uses an exponential backoff strategy by default. The only retry case you have to deal with yourself is 207s returned from the Index
API.
There is currently no API in Azure Search for proactively measuring how busy a search service is. Assuming you're not using a free service, all the capacity of your search service is dedicated to you. Your search service isn't going to know when it won't be busy again because this is entirely dependent on the load your application is putting on it. This is why we recommend an exponential backoff strategy on retries.
If you want to see how the SDK's exponential retry strategy is implemented, you can review the code on GitHub.
Upvotes: 0