2010-08-08 6 views
8

Ich arbeite mit einer Java-Twitter-App (mit Twitter4J API). Ich habe die App erstellt und kann die aktuelle Benutzer-Timeline, Benutzerprofile, etc.Rate Limit Exceeded - Benutzerdefinierte Twitter App

Allerdings scheint es bei der Verwendung der App ziemlich schnell die 150 Anfragen eine Stunde Rate Limit auf Twitter-Clients festgelegt (ich kenne Entwickler kann dies bei bestimmten Konten auf 350 erhöhen, aber das würde für andere Benutzer nicht aufgelöst werden).

Sicherlich betrifft dies nicht alle Kunden, irgendwelche Ideen, wie man das umgehen kann?

Weiß jemand, was zählt als eine Anfrage? Wenn ich zum Beispiel ein Benutzerprofil anschaue, lade ich das Benutzerobjekt (twitter4j) und hole dann den Bildschirmnamen, den Benutzernamen, die Benutzerbeschreibung, den Benutzerstatus usw. in ein JSON-Objekt - wäre dies ein einzelner Aufruf, um das Objekt zu erhalten Oder wären es mehrere, die alle user.get ... Aufrufe beinhalten?

Vielen Dank im Voraus

Antwort

4

Sie wirklich brauchen, um zu verfolgen, was Zählung Ihre aktuelle Anforderung ist, wenn sie mit Twitter zu tun.

Allerdings scheint Twitter die Zählung für 304 Not Modified nicht fallenzulassen (zumindest hat es nicht das letzte Mal, dass ich damit umgegangen bin), so stellen Sie sicher, dass es nichts gibt, was Ihre normale Verwendung von HTTP-Caching bricht, und Ihre praktische Anfrage pro Stunde steigt.

Beachten Sie, dass Twitter von einem Fehler in mod_gzip auf Apache leidet, wo der E-Tag in wechselndem es mal geformt ist zu reflektieren, dass die Inhalt-Codierung, dass die nicht-gzip-Einheit unterscheidet (dies ist die Richtige zu tun, es gibt nur einen Fehler in der Implementierung). Aus diesem Grund bedeutet das Akzeptieren von gezippten Inhalten von Twitter, dass es niemals eine 304 sendet, was die Anzahl der Anfragen erhöht und in vielen Fällen die Effizienzgewinne der Verwendung von gzip untergräbt.

Also, wenn Sie gzip akzeptieren (Ihre Web-Bibliothek kann dies standardmäßig tun, sehen Sie, was Sie mit einem Werkzeug wie Fiddler sehen können, ich bin ein .NET-Typ mit nur ein wenig Java-Kenntnisse, Antworten auf die Ebene, wie Twitter mit HTTP umgeht, so dass ich die Details von Java-Webbibliotheken nicht kenne), versuche, das auszuschalten und zu sehen, ob es Dinge verbessert.

+0

Danke für den Hinweis - Ich werde die HTTP-Caching untersuchen und stellen Sie sicher, dass ich die Anrufe entsprechend zwischenspeichern. Ich habe festgestellt, dass ein großer Teil des Problems war, dass, während ich die Liste der JSON - Objekte erstellte (zum Beispiel die aktuelle Zeitleiste), alle Daten abgerufen wurden, die möglicherweise weiter benötigt wurden (zB für jedes Update auf der Zeitleiste Ich habe alle Benutzer Informationen wie Name/Beschreibung/Num Follower usw.) abgerufen. Ich habe es so geändert, dass es nur die grundlegenden Daten für die Liste holt und dann "träge" weitere Daten holt, wenn sie benötigt werden. Danke nochmal! – rhinds

+0

FWIW, ich habe den Fehler mit der Interaktion zwischen 304 und gzip auf Twitter gemeldet. Da es sich um einen Apache-Bug handelt, wird es wahrscheinlich nicht auf ihrem Level repariert werden. Der Apache-Bug war bei Apache schon bekannt, als ich das in Twitter entdeckte. –

1

Fast jede Art von Read von Twitter-Servern (d. H. Alles, was HTTP GET aufruft) zählt als eine Anfrage. Das Einholen von User-Timelines, Retweets, direkten Nachrichten, das Abrufen von Benutzerdaten zählt jeweils als 1 Anfrage. Ziemlich genau der einzige Twitter-API-Aufruf, der vom Server liest, ohne gegen Ihr API-Limit zu zählen, besteht darin, den Status der Ratenbegrenzung zu überprüfen.