Traiter une limitation (un quota) liée à l'utilisation d'une API

Question

Actuellement avec l'API de Evernote, je me mange des "rateLimite reached" parce que je requete trop l'api en un très court lapse de temps.
Je récupere en ce moment tous les tweets de DjangoconEurope dans Evernote et Evernote rale.

2 solutions me viennent à l'esprit, une crade & rapide, une complete et moins evidente à mettre en place

la crade et rapide, quand l'exception est levée, je laisse glisser, et les tweets qui n'ont pas pu être ajoutés à Evernote partent à la poubelle

la complete, serait, quand l'exception est levée, de mettre les tweets non traités, dans un cache (genre avec cache.set() de django) et à l'execution suivante des données, je commence par lire le cache, que je traite, puis passe aux tweets que je traite et si rebelote "limite reached" je remets la suite dans le cache et ainsi de suite.

Cela vous parait-il correct ou vous auriez mieux en magasin à me proposer pour traiter ce genre de cas (qu'on doit bien rencontrer av twitter / facebok etc) ?

ps : le rateLimite n'est pas une donnée fixe fournie par l'API, elle fluctuerait selon l'utilisation qu'on en fait. Tout ce que je sais c'est que quand l'exception survient, je suis stuck 60min avant de créer de nouvelles notes.

Comments

Est-ce qu'il est envisageable que ta solution 2 n'arrive pas à suivre? si ton cache se retrouve plein lui aussi, comment tu fais?

---

Tout est envisageable oui, parce que là c'est twitter qui fourni les données (déjà ce n'est pas peu conséquent comme volume) mais si la source diffère et fournie bien plus, possible que le system de cache pète.
Donc je ne sais pas.
Je n'ai pas encore cherche à éprouver une telle archi, pour le moment je la cherche :)
Actuellement j'utilise du cache avec django & redis pour un autre service (RSS)
Je me disais que ca pouvait largement encaisser mais peut-etre que je me trompe.
Si aucun systeme de cache "à la redis" n'est foutue de gérer (ce qui serait malheureux), je vois pas mieux que de foutre le cache dans un SGBD(R), non ?

---

honnêtement je n'en sais rien, je n'utilise pas ces technos (mais je suis curieux :P )

Answer 1

la crade et rapide, quand l'exception est levée, je laisse glisser, et
les tweets qui n'ont pas pu être ajoutés à Evernote partent à la
poubelle

Pourquoi ne pas, dans le bloc catch, relancer la requete apres avoir laissé s'ecouler le temps imposé?

la complete, serait, quand l'exception est levée, de mettre les tweets
non traités, dans un cache (genre avec cache.set() de django) et à
l'execution suivante des données, je commence par lire le cache, que
je traite, puis passe aux tweets que je traite et si rebelote "limite
reached" je remets la suite dans le cache et ainsi de suite.

Mouais, ça me parait tenir la route.

Actuellement avec l'API de Evernote, je me mange des "rateLimite
reached" parce que je requete trop l'api en un très court lapse de
temps.

Un autre tuyau serait peut etre de jongler avec un celery, pr envoyer les requetes avec des intervalles, et eviter de saturer l'api sur laquelle tu tapes. J'ai aussi entendu dire que certaines API te disent le "pourquoi", et le "pendant combien de temps", lorsque tu reçois un ratelimit, ça peut t'aider a calibrer le temps entre chaque requete.

Le rate limit est en effet fonction de pas mal de choses. Une maniere d'avoir une legere influence dessus, est de limiter le nombre d'objets que tu recuperes en une fois, mais aussi, ne recuperer que les attributs de ces objets qui t'interessent, et pas le reste. Tu peux egalement verifier "s'il y a du nouveau", avant d'effectivement "recuperer", etc, ...

Comments

Pour le coup d'attendre le temps impartie : j'ai une crontab qui tourne toutes les heures. Je pourrai étaler plus , mais comme c'est un projet open source, chacun va étalonner a sa sauce....
Pour ce qui est de récupérer moins d'objets, Evernote recommande le contraire.... Ya une option withDataMachin qui rzjoute le max d'objet pour eviter d'avoir a aller les chercher plus. C'est fou mais c'est vrai...
Du coup j'ai l'impression que l'API produite par eux en python atteint ses limites.
Je vais voir pour faire une refactorisation pour ne requêter l'API le moins possible. Actuellement, pour chq tweet, je repasse tous les appels de l'api d'evernote.
Pour chaque donnee du provider je boucle sur le consumer pour créer les données avec les 'appels de l'api qui s'imposent
Probable qu'il va falloir le faire a l'envers, pour chaque consumer, récupérer les donnees du provider ,s'il y en a. Ça permettrait d'avoir une requête par consumer (meme unexpour rien s'il n'y a pas de donnes cote provider) plutot qu'une par données du provider.