Dies ist der zweite Beitrag meiner Serie über die Arbeit mit Google Drive APIs. Wenn Sie meinen ersten Artikel über Google Drive APIs noch nicht gelesen haben, sollten Sie das unbedingt nachholen. Er liefert einige Zusammenhänge, die für das Verständnis dessen, worauf ich mich beziehe, erforderlich sein könnten. Ganz zu schweigen davon, dass er auch für sich genommen nützlich sein könnte. Ich habe einige Bereiche angesprochen, die meiner Meinung nach in der Google Drive-API fehlen - z. B. Methoden, die von der Benutzeroberfläche verwendet werden und nicht öffentlich verfügbar sind. Ich habe die Einschränkungen erwähnt, die sich aus der ursprünglichen Architektur ergeben: Ordner verhalten sich wie Etiketten. Außerdem habe ich hervorgehoben, wie einige kleine Probleme im Backend von Drive einen großen Einfluss auf Produkte haben können, die es nutzen - wie Noop-Aktionen, die Änderungsbenachrichtigungen auslösen.
Beginnen wir also mit der härtesten Nuss, die zu knacken ist. Ich sage das, weil dies bei weitem die größte Blackbox war und uns die meiste Zeit gekostet hat, um sie in Übereinstimmung mit unseren Qualitätsstandards zu lösen. In vielen Fällen mussten wir uns bemühen, einen möglichst hohen Durchsatz zu erreichen, was zu mehreren Iterationen führte, um das System zu optimieren/perfektionieren. Auch wenn eine neue verfügbare Information noch so unbedeutend erschien, hätte sie leicht zu einem Refactor von beträchtlichem Umfang führen können.
Oh Mann, das ist eine Welt des Schmerzes für Sie. Kennen Sie die offizielle Empfehlung zur Abschwächung der Probleme bei Überschreitung des Ratenlimits? Verwenden Sie exponentielles Backoff. Das war's. Man sollte meinen, das würde Ihnen helfen, die API nicht unnötig mit Spam zu belasten, oder? Nein. Das ist etwas für Verlierer. Sie sind ein Profi. Lösen Sie es selbst. (Schauen Sie sich zum Beispiel an, wie die GitHub-API mit Ratenbeschränkungen umgeht, und Sie werden verstehen, wovon ich spreche). Es gibt keine offizielle Erklärung, wie sie es berechnen, wie es funktioniert, nichts. Alles, was Sie tun können, ist Benchmarks durchzuführen und auf der Grundlage der Ergebnisse Vermutungen anzustellen. Wenn Sie Glück haben, erhalten Sie vielleicht Hinweise vom Support. Abgesehen davon...
Ja, exponentielles Backoff funktioniert... und es ist genug... bis zu einem gewissen Punkt. Wenn Sie diesen Punkt erreichen und sehen, dass so viele Ihrer Ressourcen - und vor allem Geld - für Anfragen verbrannt werden, die aufgrund einer Ratenbegrenzung abgelehnt werden, sollten Sie darüber nachdenken, wie Sie das System optimieren können.
Der erste Schritt - das Ratenlimit deutlich zu unterschreiten, damit Sie keine Probleme bekommen - könnte recht einfach sein.
Der nächste Schritt hingegen - wenn Sie versuchen, so viele Anfragen wie möglich zu bearbeiten, weil Sie eine geringere Latenzzeit wünschen und/oder einfach viele Aufgaben zu erledigen haben und den Durchsatz benötigen - ist der Punkt, an dem es ziemlich knifflig wird. Im Grunde genommen müssen Sie Ihre eigene Lösung implementieren, die den Durchsatz auf der Grundlage der auftretenden Ratenbeschränkungen ändert. Verstehen Sie mich nicht falsch. Die Verwendung von exponentiellem Backoff und die Reduzierung des Durchsatzes auf unserer Seite, wenn wir die Ratengrenze erreichen, ist eine "must-have"-Funktion. Mein Problem ist, dass dies der EINZIGE Input ist, den das ganze System verwenden kann.
Und wenn das nicht ausreicht, ändert sich die Rate je nach Art der Anrufe. Hier kommen die fundierten Vermutungen ins Spiel:
Ich habe mir überlegt, ob ich nicht ein schönes Diagramm dafür erstellen soll, aber ich habe gemerkt, dass es sich noch ändern könnte, wenn Sie dies lesen. Es hat sich im Laufe der Jahre bereits mehrfach geändert. Aber seien Sie nicht traurig. Es macht mir nichts aus. Es macht mir sogar Spaß. Ich mag die Herausforderung, dieselbe Aufgabe immer und immer wieder zu stellen, um das Verhalten zu erforschen.
War es überzeugend genug? Wie dem auch sei, hoffen wir einfach, dass es immer noch gültig ist und verwenden diese relativ sicheren magischen Zahlen. Anhaltendes Lesen 10/s, anhaltendes Schreiben 1/s.
Ohh, fast vergessen. Die Geschwindigkeitsbegrenzung wird pro Benutzer angewandt, und eine Datei gehört dem Eigentümer und nicht dem Benutzer, mit dem wir die Änderung vornehmen. Wenn Sie also eine Drosselung einführen wollen, müssen Sie wissen, wem die Datei gehört. Logisch, nicht wahr? 😉 .
Noch eine Sache, die nicht so funktioniert, wie Sie es wahrscheinlich erwarten. Zumindest hat es bei mir nicht funktioniert. Als ich die Stapelverarbeitung zum ersten Mal entdeckte, dachte ich - okay, vielleicht hoffte ich -, dass eine Stapelverarbeitungsanforderung nur als eine für das Ratenlimit zählen würde. Das wäre der Himmel gewesen. Offensichtlich ist das aber nicht der Fall. Ich weiß, ich sollte nicht träumen. Okay, mein nächster Instinkt war, dass es nur dazu da ist, den Overhead der Ausführung von HTTP-Anfragen zu verringern, und dass es wie eine normale Anfrage zählt. Sogar in der Dokumentation steht das jetzt ausdrücklich. Das ist egal. Es liegt irgendwo in der Mitte. Es erhöht den Durchsatz, aber nicht auf lineare oder konsistente Weise. Wenn Sie noch keinen Bedarf für das im Abschnitt "Ratenbegrenzung" beschriebene System haben, können Sie sich glücklich schätzen, da Sie dies bis zu einem gewissen Grad nutzen können. Wenn Sie jedoch bereits über ein solches System verfügen und einen möglichst hohen Durchsatz anstreben, ist es ein weiterer unbekannter Faktor in Ihrer Gleichung. GL&HF.
Das war ziemlich einfach. Man braucht nur eine ausreichend große Ordnerstruktur mit genügend Dateien darin, die von vielen Benutzern/Gruppen gemeinsam genutzt wird... und dann fängt man an, viel zu ändern. Jede freigegebene Datei hat Abonnenten, die auf Änderungen warten. Je mehr Personen die Datei gemeinsam nutzen, desto mehr davon gibt es. Wenn Sie einen einzigen API-Aufruf tätigen, kann dieser im Backend eine Vielzahl von Ereignissen auslösen. Wenn Sie sehr viele API-Aufrufe tätigen, kommt es zu wochen-/monatelangen Warteschlangen im Drive-Backend.
Stellen Sie sich vor, Sie haben eine Ressource, die eine Listeneigenschaft hat, und Sie versuchen, diese Eigenschaft zu aktualisieren/zu patchen. Ich bin mir ziemlich sicher, dass Sie wissen, wie es sich bei leeren oder fehlenden Werten verhalten soll. Was würden Sie zum Beispiel bei einer leeren Liste erwarten? Ich würde erwarten, dass die Liste geleert wird. Nun, das ist nicht, wie drive.files.update/patch für file.parents funktioniert. Es passiert einfach nichts. Ziemlich verwirrend, wenn man bedenkt, dass es so funktioniert, wie man es erwarten würde, wenn man mindestens einen übergeordneten Wert angibt. Ich weiß, dass es die optionalen Abfrageparameter "addParents" und "removeParents" gibt, aber warum dieses inkonsistente Verhalten und warum zwingt es die Entwickler, die aktuelle Elternliste zu erhalten, bevor sie gelöscht wird? Ganz zu schweigen davon, dass es nirgendwo eine einzige Warnung oder Dokumentation gibt, die darauf hinweist, dass es so nicht funktionieren wird. Es überspringt es einfach stillschweigend. Das gleiche Problem tritt mit drive.file.copy auf. Ich würde erwarten, dass es ohne Elternteil erstellt wird, wenn ich eine leere Liste anbiete, aber es macht keinen Unterschied. Man muss buchstäblich einen weiteren Aufruf machen, um alle übergeordneten Dateien zu entfernen, die die neu kopierte Datei hat. Macht doch Sinn, oder? 😄
Die folgenden Fehler sind schon seit einer Weile behoben, aber sie sind es auf jeden Fall wert, erwähnt zu werden. Einfach um zu merken, wie viel besser es jetzt ist 🙂 .
Es gibt offensichtliche Antwortcodes wie '404 Not Found'. Einige von ihnen bedeuten, dass sie nicht einmal in den Ruhestand versetzt werden sollten. Ein Teil von ihnen sollte sofort bei der gleichen Anfrage gelöscht werden. Einige von ihnen bedeuteten, dass sie später erneut versucht werden sollten. Der Umgang mit ihnen war nie ein Problem. Die Dokumentation zu diesem Thema war viel spärlicher als heute. Um herauszufinden, was zu tun war, musste man also ausprobieren und protokollieren, welche unbehandelten Antworten man erhielt. Das war nicht sehr bequem, aber schließlich konnte man die Fehler, die man normalerweise bekommt, abdecken. Und dann, warum auch nicht, wurden ein paar dieser undokumentierten Antwortcodes ohne jede Warnung oder Dokumentation geändert. Einfach so, warum nicht. Wir waren nicht glücklich. Ganz und gar nicht.
Es gab eine Zeit, in der jede vorhandene Datei als übergeordnete Datei akzeptiert wurde. Sogar Dokumente. Das war eine nette Methode, um Dateien vor neugierigen Blicken zu verstecken, auch wenn das sicher nicht beabsichtigt war 🙂 Außerdem konnte der Besitz von Dateien auf Gruppen übertragen werden und schließlich ganz verloren gehen 🙂 Jedenfalls wurden beide Fehler inzwischen behoben.
Glücklicherweise scheint dies der Vergangenheit anzugehören, aber wenn Sie jemals einen Fehler mit der Dokumentenlisten-API erhalten haben, werden Sie ihn sicher nie vergessen. Sie erhalten eine ganze HTML-Seite in der Antwort. Einfach genial. Auch die viel bessere/neuere Google Drive-API verdient eine lobende Erwähnung. Ich meine, wer würde nicht gerne Fehlerprotokolle mit japanischen Meldungen lesen 🙂 .
Wie Sie gesehen haben, habe ich eine Menge Probleme, fehlende Funktionen und seltsame Verhaltensweisen aufgezählt, und glauben Sie mir, es gibt noch mehr 🙂 ... und ich ziehe es immer noch vor, an Anwendungen zu arbeiten, die auf GCP laufen und die Google Drive-API nutzen bzw. sich stark auf sie verlassen, gegenüber vielen anderen Alternativen, die ich nutzen könnte. Offensichtlich kommt ein großer Teil dieser subjektiven Ansicht von GCP, es geht also nicht nur um Drive 🙂 .
Und trotz meiner langen Schimpftiraden wurden die meisten dieser Probleme bereits irgendwie angegangen. Einige von ihnen wurden von Google behoben, aber für die meisten haben wir eine Art Workaround gefunden. Wissen Sie, manchmal müssen wir tatsächlich für unser Gehalt arbeiten, und es geht nicht immer darum, auf die Kompilierung/Einführung/Werkzeugausführung zu warten😉 .
