Anfrageverarbeitung

Regions-ID

REGION_ID ist ein Abkürzungscode, den Google basierend auf der Region zuweist, die Sie beim Erstellen Ihrer Anwendung ausgewählt haben. Der Code bezieht sich nicht auf ein Land oder eine Provinz, auch wenn einige Regionen-IDs häufig verwendeten Länder- und Provinzcodes ähneln. Das Einbinden von REGION_ID.r in App Engine-URLs ist für vorhandene Anwendungen optional und wird bald für alle neuen Anwendungen erforderlich sein.

Für einen reibungslosen Übergang wird App Engine nach und nach für die Verwendung von Regions-IDs aktualisiert. Wenn wir Ihr Google Cloud-Projekt noch nicht aktualisiert haben, wird für Ihre Anwendung keine Regions-ID angezeigt. Da die ID für vorhandene Anwendungen optional ist, müssen Sie keine URLs aktualisieren oder andere Änderungen vornehmen, sobald die Regions-ID für Ihre vorhandenen Anwendungen verfügbar ist.

Hier finden Sie weitere Informationen zu Regions-IDs.

In diesem Dokument wird beschrieben, wie Ihre App Engine-Anwendung Anfragen empfängt und Antworten sendet. Weitere Informationen finden Sie in der Referenz zu Anfrageheadern und Antworten.

Wenn eine Anwendung Dienste nutzt, können Sie Anfragen an einen bestimmten Dienst oder an eine bestimmte Version dieses Dienstes richten. Weitere Informationen zur Adressierbarkeit von Diensten finden Sie unter Anfragenrouting.

Verarbeitung von Anfragen

Ihre Anwendung ist für den Start eines Webservers und die Verarbeitung von Anfragen zuständig. Sie können jedes Web-Framework verwenden, das für Ihre Programmiersprache verfügbar ist.

App Engine führt mehrere Instanzen Ihrer Anwendung aus. Jede Instanz hat ihren eigenen Webserver zur Verarbeitung von Anfragen. Jede Anfrage kann an jede Instanz weitergeleitet werden. Daher werden aufeinanderfolgende Anfragen von einem Nutzer nicht zwangsläufig an dieselbe Instanz gesendet. Eine Instanz kann mehrere Anfragen gleichzeitig verarbeiten. Die Anzahl der Instanzen wird automatisch angepasst, wenn sich der Traffic ändert. Sie können auch die Anzahl der gleichzeitigen Anfragen ändern, die eine Instanz verarbeiten kann. Dazu legen Sie in der Datei app.yaml das Element max_concurrent_requests fest.

Durch einen Vergleich der Anfrage-URL mit den URL-Mustern in der Konfigurationsdatei app.yaml der Anwendung ermittelt der Server, welches PHP-Handler-Skript aufgerufen werden soll. Anschließend wird das Skript mit den Anforderungsdaten ausgeführt. Der Server fügt die Anforderungsdaten in Umgebungsvariablen und den Standardeingabestream ein. Das Skript führt die der Anfrage entsprechenden Aktionen aus und bereitet eine Antwort vor, die in den Standardausgabestream geschrieben wird.

Das folgende PHP-Skript antwortet auf jede HTTP-Anfrage mit der Nachricht "Hello World!"

<?php

echo "hello world!";

Im folgenden Beispiel wird das Slim-Framework verwendet, um eine HTTP-Anfrage zu beantworten.

$app = new Slim\App();
$app->get('/', function ($request, $response) {
    // Use the Null Coalesce Operator in PHP7
    // http://php.net/manual/en/language.operators.comparison.php#language.operators.comparison.coalesce
    $name = $request->getQueryParams()['name'] ?? 'World';
    return $response->getBody()->write("Hello, $name!");
});
$app->run();

Kontingente und Limits

App Engine weist Ihrer Anwendung automatisch Ressourcen zu, wenn der Traffic zunimmt. Dies ist jedoch an folgende Einschränkungen gebunden:

  • App Engine reserviert Kapazitäten für die automatische Skalierung von Anwendungen mit niedriger Latenz, die Anfragen in weniger als einer Sekunde beantworten. Bei Anwendungen, die bei einem hohen Anfrageaufkommen eine sehr hohe Latenz von beispielsweise über einer Sekunde pro Anfrage haben, ist Silber-, Gold- oder Platin-Support erforderlich. Kunden mit einer dieser Supportstufen können bei ihrem zuständigen Supportmitarbeiter höhere Durchsatzlimits anfordern.

  • Bei stark an CPUs gebundenen Anwendungen kann die Latenz auch geringfügig höher sein, um Ressourcen gemeinsam mit anderen Anwendungen effizient auf denselben Servern zu nutzen. Anfragen nach statischen Dateien sind von diesen Latenzbeschränkungen ausgenommen.

Alle eingehenden Anfragen an die Anwendung werden auf das Limit für Anfragen angerechnet. Die als Antwort auf eine Anfrage gesendete Daten werden auf das Limit Ausgehende Bandbreite (kostenpflichtig) angerechnet.

Sowohl HTTP- als auch (sichere) HTTPS-Anfragen werden auf die Limits Anfragen, Eingehende Bandbreite (kostenpflichtig) und Ausgehende Bandbreite (kostenpflichtig) angerechnet. In der Cloud Console werden auf der Seite "Kontingentdetails" zu Informationszwecken außerdem die Werte für Sichere Anfragen, Sichere eingehende Bandbreite und Sichere ausgehende Bandbreite als separate Werte angezeigt. In diese Werte fließen nur HTTPS-Anfragen ein. Weitere Informationen finden Sie auf der Seite Kontingente.

Die folgenden Limits gelten speziell für die Verwendung von Anfrage-Handlern:

Limit Wert
Größe der Anfrage 32 MB
Antwortgröße 32 MB
Zeitüberschreitung bei Anfrage hängt von der Art der Skalierung ab, die Ihre Anwendung verwendet
Maximale Gesamtzahl Dateien (Anwendungsdateien und statische Dateien) 10.000 insgesamt
1.000 pro Verzeichnis
Maximale Größe einer Anwendungsdatei 32 MB
Maximale Größe einer statischen Datei 32 MB
Maximale Gesamtgröße aller Anwendungsdateien und statischen Dateien Das erste 1 GB ist kostenlos
0,026 $ pro GB pro Monat nach dem ersten GB

Antwortlimits

Dynamische Antworten sind auf eine Größe von 32 MB beschränkt. Wenn ein Skript-Handler eine Antwort generiert, die diesen Grenzwert überschreitet, sendet der Server eine leere Antwort mit dem Statuscode 500 Interner Serverfehler zurück. Diese Einschränkung gilt nicht für Antworten, die Daten aus Cloud Storage bereitstellen.

Anfrageheader

Eine eingehende HTTP-Anfrage enthält die HTTP-Header, die vom Client gesendet werden. Einige Header werden aus Sicherheitsgründen von zwischengeschalteten Proxys bereinigt oder berichtigt, bevor sie die Anwendung erreichen.

Weitere Informationen finden Sie in der Referenz zu Anfrageheadern.

Zeitlimit für Anfragen setzen

App Engine ist jedoch für Anwendungen mit kurzlebigen Anfragen optimiert, die in der Regel nur wenige Hundert Millisekunden in Anspruch nehmen. Effiziente Anwendungen antworten schnell auf die meisten Anfragen. Bei Anwendungen, die nicht schnell antworten, ist es unwahrscheinlich, dass sie mit der Infrastruktur von App Engine optimal skalieren.

Ein PHP-Skript hat eine begrenzte Zeit zum Generieren und Zurückgeben von Antworten auf eine Anfrage. Wenn diese Frist abgelaufen ist, wird das TIMEOUT-Bit im Bitfeld Verbindungsstatus gesetzt. Ihr Skript hat dann eine kurze zweite Frist, um lange laufende Aufgaben zu bereinigen und eine Antwort an den Nutzer zu liefern.

Wenn Ihr Skript innerhalb der zweiten Frist keine Antwort liefert, wird der Handler beendet und eine Standardfehlerantwort zurückgegeben.

Antworten

App Engine ruft das Skript mit ausgefülltem Array $_REQUEST auf, speichert alle Ausgaben des Skripts zwischen und sendet nach Ausführung des Skripts die zwischengespeicherte Ausgabe an den Endnutzer.

Für die von Ihnen generierte Antwort gelten Größenbeschränkungen. Die Antwort kann geändert werden, bevor sie an den Client zurückgegeben wird.

Weitere Informationen finden Sie in der Referenz zu Antworten auf Anfragen.

Streamingantworten

App Engine unterstützt keine Streamingantworten, bei denen Daten in inkrementellen Blöcken an den Client gesendet werden, während eine Anfrage verarbeitet wird. Alle Daten aus Ihrem Code werden wie oben beschrieben erfasst und in einer einzigen HTTP-Antwort gesendet.

Antwortkomprimierung

Bei Antworten, die von Ihrem Code zurückgegeben werden, komprimiert App Engine die Daten in der Antwort, wenn die beiden folgenden Bedingungen erfüllt sind:

  • Die Anfrage enthält den Header Accept-Encoding, der gzip als Wert enthält.
  • Die Antwort enthält textbasierte Daten wie HTML, CSS oder JavaScript.

Bei Antworten, die von einem statischen Datei- oder Verzeichnis-Handler von App Engine zurückgegeben werden, werden die Antwortdaten komprimiert, wenn alle folgenden Bedingungen erfüllt sind:

  • Die Anfrage enthält Accept-Encoding mit einem der Werte gzip.
  • Der Client kann die Antwortdaten in einem komprimierten Format empfangen. Das Google-Front-End verwaltet eine Liste von Clients, die bekanntermaßen Probleme mit komprimierten Antworten haben. Diese Clients empfangen keine komprimierten Daten aus statischen Handlern in Ihrer Anwendung, auch wenn die Anfrage-Header Accept-Encoding: gzip enthalten.
  • Die Antwort enthält textbasierte Daten wie HTML, CSS oder JavaScript.

Wichtige Hinweise:

  • Ein Client kann erzwingen, dass textbasierte Inhaltstypen komprimiert werden. Dazu werden sowohl der Anfrageheader Accept-Encoding als auch der Header User-Agent auf gzip festgelegt.

  • Wenn gzip in der Anfrage nicht im Header Accept-Encoding angegeben ist, komprimiert App Engine die Antwortdaten nicht.

  • Das Google-Front-End speichert Antworten von statischen App Engine-Datei- und Verzeichnis-Handlern im Cache. Abhängig von verschiedenen Faktoren, z. B. welche Art von Antwortdaten zuerst im Cache gespeichert werden, welche Vary-Header Sie in der Antwort angegeben haben und welche Header in der Anfrage enthalten sind, kann ein Client komprimierte Daten anfordern, jedoch unkomprimierte Daten erhalten und umgekehrt. Weitere Informationen finden Sie unter Antwort-Caching.

Antwort-Caching

Das Google-Front-End und möglicherweise der Browser des Nutzers und andere Zwischenspeicher-Proxyserver im Cache speichern die Antworten Ihrer App gemäß den Standard-Caching-Headern, die Sie in der Antwort angeben. Sie können diese Antwortheader entweder über Ihr Framework direkt in Ihrem Code oder über App Engine statische Datei- und Verzeichnis-Handler angeben.

Im Google-Front-End ist der Cache-Schlüssel die vollständige URL der Anfrage.

Statische Inhalte im Cache speichern

Damit Clients immer aktualisierte statische Inhalte erhalten, sobald sie veröffentlicht werden, empfehlen wir, statische Inhalte aus versionierten Verzeichnissen wie css/v1/styles.css bereitzustellen. Das Google-Frontend validiert den Cache (Überprüfung auf aktualisierten Inhalt) erst, wenn der Cache abgelaufen ist. Auch nach Ablauf des Caches wird der Cache erst aktualisiert, wenn sich der Inhalt der Anfrage-URL ändert.

Die folgenden Antwortheader, die Sie in app.yaml festlegen können beeinflussen, wie und wann das Google-Front-End Inhalte im Cache speichert:

  • Cache-Control muss auf public gesetzt sein, damit der Google Fontend Inhalte im Cache speichert. Wenn Sie diesen Header nicht in app.yaml festlegen, fügt App Engine ihn automatisch für alle Antworten hinzu, die von einem statischen Datei- oder Verzeichnis-Handler verarbeitet werden. Weitere Informationen finden Sie unter Header hinzugefügt oder entfernt.

  • Vary: Damit der Cache basierend auf Headern, die in der Anfrage gesendet werden, unterschiedliche Antworten für einen URL zurückgibt, setzen Sie im Feld Vary-Anfrageheader: Accept , Accept-Encoding , Origin oder X-Origin

    Aufgrund der Möglichkeit einer hohen Kardinalität werden Daten für andere Vary-Werte nicht im Cache gespeichert.

    Beispiel:

    1. Sie geben den folgenden Antwortheader an:

      Vary: Accept-Encoding

    2. Ihre Anwendung empfängt eine Anfrage mit dem Header Accept-Encoding: gzip. App Engine gibt eine komprimierte Antwort zurück und das Google-Front-End speichert die mit gzip komprimierte Version der Antwortdaten im Cache. Alle nachfolgenden Anfragen für diese URL mit dem Header Accept-Encoding: gzip empfangen die mit gzip komprimierten Daten aus dem Cache, bis der Cache entwertet wird. Dies liegt daran, dass sich der Inhalt nach Ablauf des Caches ändert.

    3. Ihre Anwendung erhält eine Anfrage, die den Header Accept-Encoding nicht enthält. App Engine gibt eine unkomprimierte Antwort zurück und Google Front-End speichert die unkomprimierte Version der Antwortdaten im Cache. Alle nachfolgenden Anfragen für diese URL, die den Header Accept-Encoding nicht enthalten, erhalten die komprimierten Daten aus dem Cache, bis der Cache entwertet wird.

    Wenn Sie keinen Antwortheader Vary angeben, erstellt das Google-Front-End einen einzelnen Cache-Eintrag für die URL und verwendet ihn für alle Anfragen ungeachtet der Header in der Anfrage. Beispiel:

    1. Sie geben den Antwortheader Vary: Accept-Encoding nicht an.
    2. Eine Anfrage enthält den Header Accept-Encoding: gzip. Die mit gzip komprimierte Version der Antwortdaten wird im Cache gespeichert.
    3. Eine zweite Anfrage enthält nicht den Header Accept-Encoding: gzip. Da der Cache jedoch eine mit gzip komprimierte Version der Antwortdaten enthält, wird die Antwort auch dann komprimiert, wenn der Client unkomprimierte Daten angefordert hat.

Die Header in der Anfrage beeinflussen auch das Caching:

  • Wenn die Anfrage einen Authorization-Header enthält, wird der Inhalt nicht vom Google-Front-End im Cache gespeichert.

Cache-Ablauf

Standardmäßig weisen die Cache-Header, die statische Datei- und Verzeichnis-Handler der App Engine den Antworten hinzufügen, Clients und Web-Proxies wie das Google-Frontend an, den Cache nach 10 Minuten zu löschen.

Nachdem eine Datei mit einer bestimmten Ablaufzeit gesendet wurde, ist es im Allgemeinen nicht möglich, sie aus Web-Proxy-Caches zu löschen, auch wenn der Nutzer seinen eigenen Browser-Cache leert. Caches werden nicht zurückgesetzt, wenn Sie eine neue Version der Anwendung bereitstellen. Falls Sie also vorhaben, eine statische Datei zu ändern, sollte diese eine kurze Ablaufzeit von weniger als einer Stunde haben. In der Regel kann die Standardablaufzeit von 10 Minuten übernommen werden.

Sie können den Standardablauf für alle statischen Datei- und Verzeichnis-Handler ändern. Geben Sie dazu im Element in Ihrer app.yaml-Datei das Element default_expiration an. Zum Festlegen bestimmter Ablaufzeiten für unterschiedliche Handler geben Sie das Element expiration innerhalb des Handler-Elements in Ihrer app.yaml-Datei an.

Der Wert, den Sie in den Ablaufzeitelementen angeben, wird verwendet, um die HTTP-Antwortheader Cache-Control und Expires festzulegen.

HTTPS-Verbindungen erzwingen

Aus Sicherheitsgründen sollten alle Anwendungen von Clients eine Verbindung über https anfordern. Um den Browser anzuweisen, für eine bestimmte Seite oder die gesamte Domäne https http vorzuziehen, setzen Sie den Strict-Transport-Security-Header in Ihren Antworten. Beispiel:

Strict-Transport-Security: max-age=31536000; includeSubDomains
Wenn Sie diesen Header für alle statischen Inhalte festlegen möchten, die von Ihrer Anwendung bereitgestellt werden, fügen Sie den Header zu den statischen Datei- und Verzeichnis-Handlern Ihrer Anwendung hinzu.

Informationen zum Festlegen von Headers in einer Antwort, die aus Ihrem Skript generiert wird, finden Sie in der Anleitung zum Web-Framework das Sie für Ihre Anwendung verwenden. Verwenden Sie die PHP-header Funktion, wenn Sie kein Web-Framework verwenden.