Mon application est occasionnellement (une fois par jour) exécutant une insertion en vrac d'environ 1 000 fichiers. Après une poignée d'inserts, je commence à obtenir 403 réponses de limite de taux. Étant donné que mon application fait l'insertion de manière séquentielle, ma tentative de taux d'insertion n'est jamais supérieure à 1 par seconde.
J'ai vérifié que j'ai une facturation activée et que mes limites de quotas sont de plus de 100 ans par seconde, donc je ne comprends pas pourquoi je me remette si agressivement. La conséquence est que l'insert prend plus d'une heure qui n'est pas une excellente annonce pour le lecteur: - (
3 Réponses :
Vous pouvez modifier le taux de la console API. Définissez-le sur une valeur plus grande comme 10000 / sec.
Thx, mais comme je l'ai dit dans la question initiale, j'ai déjà défini le taux à 100 / sec.
Vous devez implémenter Backoff exponentiel comme explique Google dans leur documentation. < / p>
Je me rends compte que. Je finis souvent par sauvegarder pendant 4 secondes. Le point de la question est de demander si le taux d'insertion du lecteur est vraiment <1 insérer par seconde puisqu'il est vrai, j'ai besoin de redéfinir complètement mon application.
semble que la réponse est que le lecteur permettra jusqu'à 30 insertions avant de rejeter avec 403 erreurs. La figure précise et la vitesse à laquelle la limite de taux est définie n'est pas rendue publique. Voir aussi 403 La limite de taux d'insertion réussit parfois
Avez-vous obtenu ratelimitexkeeded ou USERRATELIMIMITEXEDEDED ? Au moins maintenant, il semble que vous puissiez définir la limite de demande par utilisateur de manière arbitraire dans la console API. Croissant qui devrait aider à réduire l'apparition de USERRATELIMIMITEXEDEDED exceptions si j'ai bien compris