PHP 7.4 ist jetzt allgemein verfügbar.

Anfrageverarbeitung

Regions-ID

REGION_ID ist ein abgekürzter Code, den Google anhand 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 Regions-IDs häufig verwendeten Länder- und Provinzcodes ähneln können. 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 Ihr Google Cloud-Projekt noch nicht aktualisiert wurde, 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, wenn die Regions-ID für Ihre vorhandenen Anwendungen verfügbar wird.

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 Ihre Anwendung Dienste verwendet, können Sie Anfragen an einen bestimmten Dienst oder 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 Anfragedaten 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 = AppFactory::create();
$app->addRoutingMiddleware();

$app->get('/', function (Request $request, Response $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';
    $response->getBody()->write("Hello, $name!");
    return $response;
});
$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 gesendeten Daten werden auf das Limit Ausgehende Bandbreite (kostenpflichtig) angerechnet.

Sowohl HTTP- als auch (sichere) HTTPS-Anfragen werden auf die Limits für 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 für Anwendungen mit kurzlebigen Anfragen optimiert, die in der Regel 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 und 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 mit gzip als einem Wert.
  • 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 gzip als einem der Werte.
  • 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 von statischen Handlern in Ihrer Anwendung, auch dann nicht, wenn die Anfrageheader 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 muss für die Anfrageheader Accept-Encoding und User-Agent der Wert gzip festgelegt werden.

  • Wenn gzip nicht im Header der Anfrage Accept-Encoding enthalten 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 wird, welche Vary-Header Sie in der Antwort angegeben haben und welche Header in der Anfrage enthalten sind, kann ein Client möglicherweise eine Anfrage für komprimierte Daten stellen, aber unkomprimierte Daten empfangen und umgekehrt. Weitere Informationen finden Sie unter Antwort-Caching.

Antwort-Caching

Das Google Front-End und möglicherweise der Browser des Nutzers sowie andere zwischengeschaltete Proxyserver für das Caching speichern die Antworten Ihrer Anwendung 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 statische Datei- und Verzeichnis-Handler von App Engine festlegen.

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 empfangen, sobald sie veröffentlicht werden, empfehlen wir, statische Inhalte aus versionierten Verzeichnissen wie css/v1/styles.css bereitzustellen. Das Google Front-End führt die Validierung des Caches (seine Prüfung auf aktualisierte Inhalte) erst aus, wenn der Cache abläuft. Auch nach Ablauf des Cache wird der Cache erst aktualisiert, wenn sich der Inhalt der Anfrage-URL ändert.

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

  • Für Cache-Control muss der Wert public festgelegt sein, damit das Google Front-End den Inhalt im Cache speichert. Wenn Sie diesen Header nicht in app.yaml festlegen, fügt App Engine ihn automatisch allen Antworten hinzu, die von einem statischen Datei- oder Verzeichnis-Handler verarbeitet werden. Weitere Informationen finden Sie unter Hinzugefügte oder ersetzte Header.

  • Vary: Damit der Cache basierend auf Headern, die in der Anfrage gesendet werden, unterschiedliche Antworten für eine URL zurückgeben kann, legen Sie im Vary-Anfrageheader einen oder mehrere der folgenden Werte fest: Accept, Accept-Encoding, Origin oder X-Origin

    Aufgrund einer potenziell 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 erhält 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, die den Header Accept-Encoding: gzip enthalten, empfangen die mit gzip komprimierten Daten aus dem Cache, bis der Cache ungültig wird (weil sich der Inhalt nach Ablauf des Caches ändert).

    3. Ihre Anwendung erhält eine Anfrage ohne den Header Accept-Encoding. App Engine gibt eine unkomprimierte Antwort zurück und das 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, empfangen die komprimierten Daten aus dem Cache, bis der Cache ungültig wird.

    Wenn Sie keinen Vary-Antwortheader festlegen, erstellt das Google Front-End einen einzelnen Cache-Eintrag für die URL und verwendet ihn für alle Anfragen, unabhängig von den Headern in der Anfrage. Beispiel:

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

Die Header in der Anfrage haben auch Auswirkungen auf das Caching:

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

Cache-Ablauf

Die Caching-Header, die den Antworten durch statische Datei- und Verzeichnis-Handler von App Engine hinzugefügt werden, weisen Clients und Webproxys wie das Google Front-End standardmäßig an, den Cache nach 10 Minuten ablaufen zu lassen.

Nachdem eine Datei mit einer bestimmten Ablaufzeit gesendet wurde, ist es im Allgemeinen nicht möglich, sie aus Webproxy-Caches zu löschen, auch wenn der Nutzer seinen eigenen Browser-Cache löscht. Caches werden nicht zurückgesetzt, wenn Sie eine neue Version der Anwendung bereitstellen. Falls Sie also jemals 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 die Standardablaufzeit für alle statischen Datei- und Verzeichnis-Handler ändern. Geben Sie dazu in Ihrer Datei app.yaml das Element default_expiration an. Zum Festlegen bestimmter Ablaufzeiten für einzelne Handler legen Sie das Element expiration innerhalb des Handler-Elements in Ihrer Datei app.yaml fest.

Der Wert, den Sie für die Ablaufzeit der Elemente angeben, wird zum Festlegen der HTTP-Antwortheader Cache-Control und Expires verwendet.

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 für die gesamte Domain https statt http zu verwenden, legen Sie in Ihren Antworten den Header Strict-Transport-Security fest. Beispiel:

Strict-Transport-Security: max-age=31536000; includeSubDomains
Zum Festlegen dieses Headers für statische Inhalte, die von Ihrer Anwendung bereitgestellt werden, fügen Sie den Header den statischen Datei- und Verzeichnis-Handlern Ihrer Anwendung hinzu.

Informationen zum Festlegen von Headern 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.