google appengine/python: Kann ich mich darauf verlassen, dass die Wiederholung der Task-Warteschlange bei einem Fehler die Einfügungen auf ein Minimum beschränkt?

Question

Angenommen, meine App enthält eine Seite, auf der Personen Kommentare hinzufügen können. Sagen Sie, nachdem jeder Kommentar hinzugefügt wurde, wird ein Task-Queue-Worker hinzugefügt. Wenn also 100 Kommentare hinzugefügt werden, werden 100 Einfügungen durchgeführt.

(Anmerkung: Die oben ist ein hypothetisches Beispiel, meine Frage zu illustrieren)

sage ich, dass die Anzahl von Einfügungen, um sicherzustellen, wollte ein gering wie möglich gehalten werden (so laufe ich nicht in die 10k Einfügung Grenze)

Konnte ich etwas wie folgt tun.

a) Da jeder Kommentar hinzugefügt wird Anruf taskqueue.add (name = "stickytask", url = "/ blah") - Da es sich um eine benannte taskqueue es nicht, wenn ein wieder eingesetzt werden taskqueue von Derselbe Name existiert.

b) Die/blah Arbeiter url liest die neu hinzugefügten Kommentare, verarbeitet die ersten und , als wenn mehr Kommentare vorhanden verarbeitet, um einen Statuscode andere als 200 kehrt zu werden - Dadurch wird sichergestellt, dass die Aufgabe erneut versucht wird, und beim nächsten Versuch wird den nächsten Kommentar und so weiter verarbeiten.

Also alle 100 Kommentare werden mit 1 oder ein paar Taskqueue Insertion verarbeitet. (Anmerkung: Wenn es eine Flaute in Tätigkeit, bei der keine neuen Kommentare hinzugefügt werden und alle Kommentare sind verarbeitet als die nächsten Kommentar hinzugefügt in einer neuen taskqueue Insertion führen wird.)

jedoch von der Dokumentation (siehe Code-Schnipsel unten) merkt es an, dass "das System sich allmählich zurückzieht". Bedeutet dies, dass auf jedem "nicht 200" Http Statuscode eine Verzögerung zurückgegeben wird, die in den nächsten Wiederholungsversuch eingefügt wird?

Aus der Dokumentation: Wenn die Ausführung einer bestimmten Aufgabe nicht (durch die HTTP-Statuscode andere als 200 OK zurückkehrt), wird App Engine erneut zu versuchen, versuchen, bis es gelingt. Das System wird schrittweise zurückgesetzt, um Ihre Anwendung nicht mit zu vielen Anfragen zu überschwemmen, aber es wird mindestens einmal pro Tag mindestens einmal am Tag eine fehlgeschlagene Aufgabe wiederholt.

Answer 1

Es gibt keinen Grund, einen Fehler vorzutäuschen (und Backoff zu verursachen & c) - das ist ein hacky und zerbrechliches Arrangement. Wenn Sie befürchten, dass das Einplanen einer Aufgabe für einen neuen Kommentar die derzeit strengen Grenzen der Aufgabenwarteschlangen überschreiten könnte, dann "noch nicht verarbeitete Kommentare im Laden" (und möglicherweise auch in Memcache, für eine mögliche Beschleunigung, aber, das ist optional) und planen Sie keine Aufgabe zu diesem Zeitpunkt.

vielmehr einen cron-Job halten Ausführung (sagen wir) jede Minute, die mit einigen Kommentaren umgehen können oder eine entsprechende Anzahl von Aufgaben planen mit ausstehenden Kommentare behandeln - wie Sie Aufgaben aus nur einem Cron-Job zu planen, ist es leicht zu Stellen Sie sicher, dass Sie nie mehr als 10.000 pro Tag planen.

Lassen Sie Task-Queues nicht vergessen, dass cron auch vorhanden ist: Eine gute Architektur für "Batch-ähnliche" Verarbeitung verwendet in der Regel sowohl Cron-Jobs als auch Aufgaben in der Warteschlange, um das Gesamtdesign zu vereinfachen.

Um die Menge an nützlicher Arbeit zu maximieren, die in einer einzigen Anfrage ausgeführt wird (von Ether eine Aufgabe in der Warteschlange oder eine Cron), betrachten Sie einen Ansatz basierend auf monitoring Ihre CPU-Auslastung - wenn CPU der Faktor ist, der die Arbeit beschränkt Auf diese Weise können Sie pro Anfrage so viele kleine planbare Arbeitseinheiten in einer einzigen Anfrage erledigen, wie es vernünftigerweise möglich ist. Ich denke, diese Herangehensweise ist solider als das Warten auf eine OverQuotaError, das Abfangen und das schnelle Schließen, da dies andere Konsequenzen aus der Kontrolle Ihrer App haben kann.