Warum werden GET-Anforderungen an die Web App meines Google Apps-Skripts zeitweise überschritten?

Question

In regelmäßigen Abständen kommt keine Antwort von meiner GAS-Web-App zurück, obwohl ich identische Anrufe über GET gemacht habe. Stattdessen meldet die aufrufende Anwendung eine Zeitüberschreitung, nachdem sie 15+ Sekunden gewartet hat *.

Ich habe hurl.it benutzt (mit 'Follow Redirects' Set) - ein ausgezeichnetes Testwerkzeug! - ebenso wie der Twilio-Messaging-Dienst dieselbe URL, Parameter, Werte usw. aufrufen und feststellen, dass die Antwortzeit abgelaufen ist, als ob der beabsichtigte Google Apps Script-Code nie ausgeführt würde.

Die Timeouts sind intermittierend, ohne Muster hinsichtlich Tageszeit, URL, Payload (GET-Parameter), usw. Außerdem funktioniert der zugrunde liegende GAS-Code zu allen anderen Zeiten fehlerfrei.

Beispiel GET-Anfrage: https://script.google.com/macros/s/AKfycbw5LddY3SIv-dD6U_1ibAy7cGog5WjmHyDDUSyBq0G2k9gZ3rkI/exec?MessageSid=1234&From=+8081234567&Body=newman

Expected XML-Antwort: <Response><Sms>Timothy has sent you ...</Sms></Response>

* HINWEIS: Der zugrunde liegende Code GAS, deren Leistung nicht Faktor in mein Dilemma scheint, führt typischerweise in 0,125 Sekunden, wenn Antworten komm durch.

Während der Fehlerbehebung habe ich die "offensichtlichen Dinge" doppelt und dreifach überprüft, z. B. die Bereitstellung des neuesten Codes als Web App ..., um sicherzustellen, dass der Code selbst eine doGet() - Funktion enthält Dienste wurden autorisiert, Benutzerberechtigungen werden auf "Jeder (auch anonym)" usw. festgelegt.

Mein Verdacht an dieser Stelle (nennen Sie es mein Witz Ende) ist, dass Googles Server einfach nicht zu zufälligen Zeiten reagieren, und dies verursacht einen schweren Rückstand in meiner Arbeit. Alle Einsichten sehr geschätzt! Ich habe dieses und andere Foren gründlich auf ähnliche Beschwerden überprüft, ohne Erfolg.

DANKE IM VORAUS!

Answer 1

FINAL (gültig?) „Lösung“

ich auch lock.tryLock(10000) (siehe GAS-Dokumentation) zu Beginn meines Skripts implementiert, so dass Trigger-basierende und Instanzen von meiner Code-GET angefordert würde nicht über jede Reise andere. Ebenso habe ich SpreadsheetApp.flush() am Ende von Skripten/Funktionen hinzugefügt, die Tabellenkalkulationsdaten ändern, um Kollisionen zu verhindern.

Ironischerweise auf mein Projekt der BetterLog Bibliothek hinzugefügt wird sie eingeführt eigenen Timeout Problem zu haben, und zwar mit dem Einsatz von getLastRow() in seinem Code. Eine sorgfältige Beobachtung von View> Execution Transcript (glücklicherweise protokolliert BetterLog auch seine eigene Aktivität im nativen Logger!) Ergab, dass Instanzen von getLastRow() 10-20 Sekunden benötigten jeweils zur Ausführung! Ich halte dies für einen echten Fehler innerhalb von GAS und habe daher einen gründlichen Fehlerbericht über den Google-Problem-Tracker eingereicht.

Hier ist eine Beispielzeile um das Problem zu demonstrieren (die intermittierende bleibt):
[16-06-11 07: 11: 13: 980 CDT] Sheet.getLastRow() [20,141 Sekunden]

HALB ENDGÜLTIG (fast gültig?) "LÖSUNG"

Über den einzigen verbliebenen Trick in meiner Tasche war zu sehen, ob Code-Kollisionen hinter den Kulissen stattfanden. Letztendlich, nach dem Deaktivieren eines vorhandenen Projekt-Triggers (der auf jede Minute gesetzt wird), verschwand das Timeout-Problem!Das macht mich widerwillig, diesen (sehr notwendigen) Trigger neu zu starten, aber die wissenschaftliche Methode verlangt, dass ich das tue, um zu sagen, ob das Timeout-Problem zurückkehrt.

HINWEIS: Ich frage mich natürlich, WARUM eine perfekt funktionierende Codebasis so leicht von zwei parallel laufenden (unabhängigen) Unterprogrammen ausgelöst wird? Mein Verdacht ist, dass, da beide die gleichen Funktionen nutzen und auf die gleiche zugrundeliegende Tabelle zugreifen, die Gefahr besteht, dass eine (unangekündigte) Sperre Verletzung wird. Warum dies sich als Timeouts (anstelle von Fehlermeldungen) manifestieren würde, ist mir nicht bekannt, aber es genügt zu sagen, dass meine erweiterten Protokollierungsbemühungen (siehe unten) deutlich zeigen, dass die Laufzeit von 0,3 Sekunden auf etwa 60 Sekunden steigt (!!) wenn es auftritt.

ORIGINAL (ungültig) "Lösung"

Das zugrunde liegende Problem erschien auf die Verwendung von GAS nativen Logger-Funktion verbunden werden. Das Entfernen von Instanzen von Logger.log() aus meinem Code führte fast sofort zu einem verbesserten Timing, bis zu dem Punkt, an dem die App für eine lange Zeitspanne auf jede einzelne GET-Anfrage reagiert.

Dementsprechend implementiert ich Peter Herrmann trefflichsten Helfer Bibliothek BetterLog (siehe https://github.com/peterherrmann/BetterLog) meine Protokollierung Bedürfnisse zu dienen, mit der Aktivität auf ein neues Blatt aufgezeichnet wird (entsprechend dem Namen ‚Logs‘) innerhalb der angeschlossenen Tabelle in Google Drive.

In den folgenden zwei Stunden blieb die Reaktionszeit der Web App bei 100% ... das ursprüngliche Problem kehrte jedoch später am selben Nachmittag zurück, woraufhin die Reaktionsfähigkeit auf 0% fiel.

Wird bei weiteren Einsichten weiter aktualisiert (oder diese Antwort bearbeiten)!