Conseils de limitation des API pour Azure Data Manager for Agriculture
La limitation restreint le nombre de requêtes pouvant être adressées à un service dans un laps de temps donné pour empêcher la surutilisation de ressources. La limitation de l’API REST dans Azure Data Manager for Agriculture permet d’obtenir des performances plus cohérentes dans un laps de temps pour les clients qui appellent les API du service.
Azure Data Manager for Agriculture peut gérer un volume élevé de demandes. Dans le cas de demandes extrêmement nombreuses provenant de quelques clients, cette limitation permet de maintenir des performances optimales et la fiabilité pour tous les clients.
La limitation dépend de la version sélectionnée et des fonctionnalités du produit qu’un client utilise. Azure Data Manager for Agriculture prend en charge deux versions distinctes :
- Standard : version que nous recommandons généralement.
- Essentiel : version adaptée aux exigences de prototypage.
Ces limites sont valables dans trois fenêtres de temps (une minute, cinq minutes et un mois) afin d’assurer une protection contre les pics de trafic soudains.
Cet article vous montre comment suivre le nombre de demandes qui restent avant d’atteindre la limite et comment réagir quand vous avez atteint la limite. La limitation s’applique à ces API.
Classification des API
Les API Azure Data Manager for Agriculture se répartissent en trois catégories principales :
- Opérations d’écriture : API qui utilisent des méthodes d’API REST telles que
PATCH,POSTetDELETEpour modifier les données. - Opérations de lecture : API qui utilisent le type de méthode d’API REST
GETpour récupérer des données, y compris les API de recherche du type de méthodePOST. - Opérations de travail longues : API asynchrones d’opérations longues qui utilisent le type de méthode d’API REST
PUT.
Les unités de quota disponibles globales, comme expliqué dans le tableau suivant, sont partagées entre ces catégories. Par exemple, l’utilisation du quota entier sur les opérations d’écriture signifie qu’aucun quota restant n’est utilisé pour les autres opérations. Chaque opération consomme une unité de quota spécifique, ce qui vous permet de suivre le quota restant pour une utilisation supplémentaire.
| Opération | Coût unitaire pour chaque requête |
|---|---|
| Écrire | 5 |
| Lire | 1 1 |
| Travail de longue durée : inférence de solution | 5 |
| Travail de longue durée : exploitations agricoles | 5 |
| Travail de longue durée : rastérisation d’image | 2 |
| Travail de longue durée : suppression en cascade d’une entité | 2 |
| Travail de longue durée : ingestion météo | 1 |
| Travail de longue durée : ingestion satellite | 1 |
1Un coût unitaire supplémentaire est pris en compte pour chaque élément retourné dans la réponse lorsque vous récupérez plusieurs éléments.
Limites d’API pour la version Essentiel
Le tableau suivant répertorie les unités disponibles totales par catégorie pour la version Essentiel :
| Opération | Fenêtre de temps de limitation | Unités réinitialisées après chaque fenêtre de temps |
|---|---|---|
| Écriture/lecture | Une minute | 25 000 |
| Écriture/lecture | Cinq minutes | 100 000 |
| Écriture/lecture | Un mois | 5,000,000 |
| Travail de longue durée | Cinq minutes | 1 000 |
| Travail de longue durée | Un mois | 100 000 |
Limites d’API pour la version Standard
La version Standard offre un quota d’API mensuel cinq fois supérieur à celui de la version Essentiel. Toutes les autres limites de quota restent inchangées.
Le tableau suivant répertorie les unités disponibles totales par catégorie pour la version Standard :
| Opération | Fenêtre de temps de limitation | Unités réinitialisées après chaque fenêtre de temps |
|---|---|---|
| Écriture/lecture | Une minute | 25 000 |
| Écriture/lecture | Cinq minutes | 100 000 |
| Écriture/lecture | Un mois | 25 000 000 1 |
| Travail de longue durée | Cinq minutes | 1 000 |
| Travail de longue durée | Un mois | 500 000 1 |
1Cette limite est cinq fois supérieure à celle de la version Essentiel.
Code d'erreur
Lorsque vous atteignez la limite, vous recevez le code d’état HTTP 429 Trop de requêtes. La réponse inclut une valeur Retry-After qui spécifie le nombre de secondes pendant lesquelles votre application doit attendre (ou rester en veille) avant d’envoyer la requête suivante.
Si vous envoyez une demande avant l’écoulement de la valeur de nouvelles tentatives, votre demande n’est pas traitée et une autre valeur de nouvelles tentatives est renvoyée. Une fois le temps spécifié écoulé, vous pouvez à nouveau effectuer des demandes auprès d’Azure Data Manager for Agriculture. La tentative d’établissement d’une connexion TCP ou l’utilisation d’autres méthodes d’authentification utilisateur ne contourne pas ces limites, car elles sont spécifiques à chaque locataire.
Forum aux questions
Si j’épuise entièrement le quota d’API alloué pour les opérations d’écriture dans une fenêtre de temps par minute, puis-je effectuer des demandes d’opérations de lecture dans la même fenêtre de temps ?
Les limites de quota sont partagées entre les catégories d’opérations répertoriées. L’utilisation du quota entier pour les opérations d’écriture signifie qu’aucun quota restant n’est utilisé pour les autres opérations. Cet article détaille les unités de quota spécifiques consommées pour chaque opération.
Comment puis-je calculer le nombre total de demandes réussies autorisées pour une fenêtre de temps particulière ?
Le nombre total autorisé de demandes d’API réussies dépend de la version que vous avez approvisionnée et de la fenêtre de temps dans laquelle vous effectuez les demandes.
Par exemple, avec la version Standard, vous pouvez effectuer 25 000 (unités réinitialisées après chaque fenêtre de temps) / 5 (coût unitaire pour chaque requête) = 5 000 API d’opérations d’écriture dans une fenêtre de temps d’une minute. Vous pouvez également utiliser une combinaison de 4 000 opérations d’écriture et 5 000 opérations de lecture, soit 4 000 * 5 + 5 000 * 1 = 25 000 unités totales de consommation.
De même, pour la version Essentiel, vous pouvez effectuer 5 000 000 (unités réinitialisées après chaque fenêtre de temps) / 1 (coût unitaire pour chaque requête) = 5 000 000 API d’opérations de lecture dans une fenêtre de temps d’un mois.
Combien d’événements de capteur un client peut-il ingérer au maximum ?
Le système autorise un maximum de 100 000 ingestions d’événements par heure. Bien que de nouveaux événements soient continuellement acceptés, il peut y avoir un retard dans le traitement. Le retard peut indiquer que ces événements ne sont pas immédiatement disponibles pour les scénarios de sortie en temps réel en même temps que l’ingestion.