Memcache API für gebündelte Legacy-Dienste

Diese Seite bietet eine Übersicht über den Memcache-Dienst von App Engine. Leistungsfähige, skalierbare Webanwendungen verwenden für einige Aufgaben häufig einen verteilten speicherinternen Datencache vor einem robusten nichtflüchtigen Speicher oder anstelle dieses Speichers. App Engine bietet für diesen Zweck einen Speicher-Cache-Dienst. Informationen zum Konfigurieren, Überwachen und Verwenden des Memcache-Dienstes finden Sie unter Memcache verwenden.

Gründe für die Verwendung eines Memcache

Ein Speicher-Cache dient u. a. dazu, häufige Datenspeicherabfragen zu beschleunigen. Wenn viele Anfragen dieselbe Abfrage mit denselben Parametern senden und Änderungen an den Ergebnissen nicht sofort auf der Website angezeigt werden müssen, kann die Anwendung die Ergebnisse im Memcache zwischenspeichern. Nachfolgende Anfragen können den Memcache prüfen und erst dann die Datenspeicherabfrage ausführen, wenn Ergebnisse nicht vorhanden oder abgelaufen sind. Sitzungsdaten, Nutzereinstellungen und andere Daten, die von Abfragen für Webseiten zurückgegeben werden, eignen sich gut für das Caching.

Memcache kann für andere temporäre Werte nützlich sein. Wenn Sie jedoch erwägen, einen Wert ausschließlich im Memcache zu speichern und nicht in einem anderen nichtflüchtigen Speicher zu sichern, müssen Sie dafür sorgen, dass Ihre Anwendung bei plötzlicher Nichtverfügbarkeit des Werts auf angemessene Weise reagiert. Werte im Memcache können jederzeit ablaufen und vor dem für den Wert festgelegten Ablauftermin erlöschen. Wenn beispielsweise Sitzungsdaten eines Nutzers plötzlich nicht mehr verfügbar sind und dies zu einer fehlerhaften Sitzung führen würde, sollten diese Daten möglicherweise nicht nur im Memcache, sondern auch im Datenspeicher gespeichert werden.

Dienstebenen

App Engine unterstützt zwei Ebenen des Memcache-Dienstes:

  • Freigegebener Memcache ist der kostenlose Standard für App Engine-Anwendungen. Er bietet Cachekapazität auf Best-Effort-Basis und richtet sich nach der allgemeinen Nachfrage aller App Engine-Anwendungen, die den freigegebenen Memcache-Dienst nutzen.

  • Dedizierter Memcache bietet eine feste Cachekapazität, die exklusiv Ihrer Anwendung zugewiesen ist. Er wird nach Cachegröße in GB/Stunde in Rechnung gestellt und erfordert, dass die Abrechnung aktiviert ist. Wenn Sie Kontrolle über die Cachegröße haben, kann Ihre Anwendung vorhersehbarer und mit weniger Lesevorgängen aus dem teureren langlebigen Speicher ausgeführt werden.

Beide Memcache-Dienstebenen nutzen dieselbe API. Informationen zum Konfigurieren des Memcache-Dienstes für Ihre Anwendung finden Sie unter Memcache verwenden.

In der folgenden Tabelle werden die Unterschiede zwischen den beiden Memcache-Dienstklassen zusammengefasst:

Funktion Dedizierter Memcache Freigegebener Memcache
Preis 0,06 $ pro GB/Stunde Kostenlos
Kapazität
us-central
1 bis 100 GB
asia-northeast1, europe-west, europe-west3 und us-east1:
1 bis 20 GB
Andere Regionen:
1 bis 2 GB
 Keine garantierte Kapazität
Leistung Bis zu 10.000 Lesevorgänge oder 5.000 Schreibvorgänge (exklusiv) pro Sekunde und GB (Elemente < 1 KB). Weitere Einzelheiten finden Sie unter Cachestatistiken. Nicht garantiert
Langlebige Speicherung Nein Nein
SLA Keine Keine

Die Abrechnung des dedizierten Memcache erfolgt in 15-Minuten-Schritten. Wenn Sie in einer anderen Währung als US-Dollar bezahlen, gelten die Preise, die unter Cloud Platform SKUs für Ihre Währung angegeben sind.

Wenn Ihre Anwendung mehr Memcache-Kapazität benötigt, wenden Sie sich an unser Vertriebsteam.

Limits

Für die Verwendung des Memcache-Diensts gelten die folgenden Limits:

  • Die maximale Größe eines zwischengespeicherten Datenwerts beträgt 1 MiB (2^20 Byte) minus die Größe des Schlüssels und abzüglich eines implementierungsabhängigen Overheads, der ungefähr bei 73 Byte liegt.
  • Ein Schlüssel darf nicht größer als 250 Byte sein. Wenn Sie in der PHP-Laufzeit versuchen, für Memcache einen größeren Schlüssel festzulegen, löst der Aufruf eine Ausnahme aus. Andere Laufzeiten verhalten sich anders.
  • "Multi"-Batchvorgänge können eine beliebige Anzahl von Elementen haben. Die Gesamtgröße des Aufrufs und die Gesamtgröße der abgerufenen Daten dürfen jeweils 32 Megabyte nicht überschreiten.
  • Ein Memcache-Schlüssel darf kein Nullbyte enthalten.

Empfehlungen und Best Practices

Bei der Verwendung von Memcache sollten Sie Ihre Anwendungen so entwerfen, dass sie:

  • Darauf vorbereitet sind, wenn ein im Cache gespeicherter Wert nicht verfügbar ist

    • Memcache ist kein langfristiger Speicher. Gemäß der Bereinigungsrichtlinie werden Schlüssel bereinigt, wenn sich der Cache füllt. Außerdem kann der Cache aufgrund von Änderungen an der Cachekonfiguration oder Wartungsarbeiten im Rechenzentrum teilweise oder vollständig geleert werden.
    • Memcache kann vorübergehend nicht verfügbar sein. Memcache-Vorgänge können aus verschiedenen Gründen fehlschlagen, einschließlich Änderungen in der Cache-Konfiguration oder Wartungsarbeiten im Rechenzentrum. Anwendungen sollten so konzipiert sein, dass fehlgeschlagene Vorgänge abgefangen werden, ohne diese Fehler den Endnutzern anzuzeigen. Diese Empfehlung gilt insbesondere für Set-Vorgänge.

  • Nach Möglichkeit die Batchfunktion der API verwenden

    • Hierdurch wird die Leistung und Effizienz der Anwendung erhöht, insbesondere bei kleinen Elementen.

  • Verteilen Sie die Last über Ihren Memcache-Schlüsselraum.

    • Wenn ein einzelnes Memcache-Element oder ein kleiner Satz von Memcache-Elementen ein unverhältnismäßiges Volumen an Zugriffen darstellt, wird die Skalierung der Anwendung beeinträchtigt. Diese Empfehlung gilt sowohl für Vorgänge pro Sekunde als auch für die Bandbreite. Sie können dieses Problem häufig durch eine explizite Fragmentierung der Daten beheben.

      Sie können beispielsweise einen häufig aktualisierten Zähler auf mehrere Schlüssel aufteilen, sie zurücklesen und nur addieren, wenn Sie eine Gesamtsumme benötigen. Ebenso lassen sich 500 KB an Daten, die bei jeder HTTP-Anfrage gelesen werden müssen, auf mehrere Schlüssel aufteilen und dann mit einem einzigen API-Batchaufruf zurücklesen. (Noch besser ist es, den Wert im Instanzspeicher zwischenzuspeichern.) Bei dediziertem Memcache sollte die maximale Zugriffsrate für einen einzelnen Schlüssel um ein bis zwei Größenordnungen unter der Pro-GB-Rate liegen.

  • Ihre eigenen Schlüssel beibehalten, um Werte aus dem Cache abzurufen

    • Memcache bietet keine Methode zum Auflisten von Schlüsseln. Aufgrund der Art des Caches ist es nicht möglich, Schlüssel aufzulisten, ohne den Cache zu unterbrechen. Darüber hinaus sind einige Sprachen wie Python, lange Hash-Schlüssel und die ursprünglichen Schlüssel nur der Anwendung bekannt.

PHP-Memcache-Implementierung

App Engine enthält Implementierungen der standardmäßigen Memcache API und der Memcached APIs, die beide intern den App Engine-Memcache-Dienst aufrufen. Einige Funktionen können zwar aufgerufen werden ("Stub"-Funktionen), haben aber keine Funktionalität, da sie im Kontext einer App Engine-Anwendung nicht benötigt werden. Daher werden Aufrufe der folgenden Funktionen ignoriert:

Stub-Funktionen in der Memcache API

  • memcache_add_server()
  • memcache_close()
  • memcache_connect()
  • memcache_pconnect()
  • memcache_set_compress_threshold()
  • addServer()
  • close()
  • connect()
  • pconnect()
  • setCompressThreshold()

Stub-Funktionen in der Memcached API

  • addServer()
  • addServers()
  • getAllKeys()
  • getServerByKey()
  • getServerList()
  • getStats()
  • getVersion()
  • isPersistent()
  • isPristine()
  • quit()
  • resetServerList()
  • setSaslAuthData()

Das folgende Beispiel zeigt die Verwendung der Memcache PHP API in App Engine:

$memcache = new Memcache;
return $memcache->get($key);

Das folgende Beispiel veranschaulicht die Verwendung der Memcached PHP API in App Engine:

$memcache = new Memcached;
$memcache->set('who', $request->get('who'));
return $twig->render('memcache.html.twig', [
    'who' => $request->get('who'),
    'count' => $memcache->increment('count', 1, 0),
    'host' => $request->getHost(),
]);

Ablauf von Daten im Cache

Memcache enthält Schlüssel/Wert-Paare. Die im Speicher enthaltenen Paare ändern sich, wenn Elemente in den Cache geschrieben und aus diesem abgerufen werden.

Standardmäßig werden im Memcache gespeicherte Daten so lange wie möglich beibehalten. Werte können aus dem Cache entfernt werden, wenn dem Cache ein neuer Wert hinzugefügt wird und nicht genügend Speicher vorhanden ist. In diesem Fall werden die Werte, deren letzte Verwendung am längsten zurückliegt, zuerst entfernt.

Die Anwendung kann beim Speichern eines Werts eine Ablaufzeit festlegen, und zwar entweder als Sekundenzahl ab dem Zeitpunkt des Hinzufügens des Werts oder als absolute Sekundenzahl seit der Unix-Epoche, also dem 1. Januar 1970, Mitternacht. Der Wert wird spätestens zu diesem Zeitpunkt entfernt, er kann jedoch aus anderen Gründen auch früher entfernt werden. Wenn Sie den Wert erhöhen, der für einen vorhandenen Schlüssel gespeichert ist, wird dessen Ablaufzeit nicht aktualisiert.

In seltenen Fällen können Werte auch aus anderen Gründen als Speicherauslastung vor dem Ablauf aus dem Cache entfernt werden. Memcache kann zwar Serverfehlern standhalten, doch werden Memcache-Werte nicht auf einem Laufwerk gespeichert. Somit können Dienstfehler dazu führen, dass Werte nicht mehr verfügbar sind.

Im Allgemeinen sollte eine Anwendung nicht davon ausgehen, dass im Cache gespeicherte Werte immer zur Verfügung stehen.

Sie können den gesamten Cache einer Anwendung über die API oder im Memcache-Bereich der Google Cloud Console löschen.

Cache-Statistiken

Vorgänge pro Sekunde nach Elementgröße

Dedizierter Memcache wird in Vorgängen pro Sekunde und GB bemessen, wobei ein Vorgang als einzelner Zugriff auf ein Cache-Element definiert ist (z. B. get, set oder delete). Die Vorgangsrate variiert in Abhängigkeit von der Elementgröße, wie der folgenden Tabelle zu entnehmen ist. Ein Überschreiten dieser Werte kann zu erhöhten API-Latenzzeiten oder Fehlern führen.

Die folgende Tabelle enthält die maximale Anzahl von gehaltenen, ausschließlichen get-hit- oder set-Vorgängen pro GB Cache. Beachten Sie, dass ein get-hit-Vorgang ein get-Aufruf ist, bei dem festgestellt wird, dass ein Wert mit dem angegebenen Schlüssel gespeichert ist, und der diesen Wert zurückgibt.

Elementgröße (KB) Höchstens get-hit Vorgänge pro Sekunde Höchstens set Vorgänge pro Sekunde
≤1 10.000 5.000
100 2.000 1.000
512 500 250

Eine Anwendung, die für mehrere GB an Cache konfiguriert ist, kann theoretisch eine Gesamtvorgangsrate erzielen, die sich aus der Anzahl von GB multipliziert mit der Rate pro GB berechnet. Beispiel: Eine Anwendung, die für 5 GB an Cache konfiguriert ist, kann 50.000 Memcache-Vorgänge pro Sekunde für Elemente von 1 KB erreichen. Das Erreichen dieser Ebene erfordert eine gute Lastverteilung über den Memcache-Schlüsselraum.

Die oben aufgeführten Limits beziehen sich auf Lese- oder Schreibvorgänge für jedes E-/A-Schema. Bei gleichzeitigen Lese- und Schreibvorgängen bewegen sich die Limits auf einer Gleitskala. Je mehr Lesevorgänge stattfinden, desto weniger Schreibvorgänge können ausgeführt werden und umgekehrt. Alle der folgenden Werte sind Beispiel-IOPS-Limits für gleichzeitige Lese- und Schreibvorgänge von 1 KB großen Werten pro 1 GB Cache:

Lese-IOPS Schreib-IOPS
10000 0
8.000 1.000
5.000 2.500
1.000 4.500
0 5.000

Memcache-Recheneinheiten (MCU)

Der Memcache-Durchsatz kann abhängig von der Größe des Elements, auf das Sie zugreifen, und dem Vorgang, den Sie für das Element ausführen möchten, variieren. Mit einer Einheit namens Memcache-Recheneinheit (Memcache Compute Unit, MCU) können Sie Vorgängen ungefähre Kosten zuordnen und die von einem dedizierten Memcache zu erwartende Zugriffskapazität schätzen. Die MCU ist so definiert, dass Sie 10.000 MCU pro Sekunde und GB an dediziertem Memcache erwarten können. In der Google Cloud Console wird angezeigt, wie viel MCU die Anwendung derzeit nutzt.

MCU ist eine grobe statistische Schätzung und außerdem keine lineare Einheit. Jeder Cachevorgang, der einen Wert liest oder schreibt, ist mit entsprechenden MCU-Kosten verbunden, die von der Größe des Werts abhängen. Wie viel MCU ein set-Vorgang beansprucht, hängt von der Größe des Werts ab. Er kostet zweimal so viel wie ein erfolgreicher get-hit-Vorgang.

Größe des Wertelements (KB) MCU-Kosten für get-hit MCU-Kosten für set
≤1 1,0 2,0
2 1.3 2,6
10 1,7 3.4
100 5.0 10,0
512 20.0 40,0
1.024 50,0 100,0

Vorgänge, die keinen Wert lesen oder schreiben, haben feste MCU-Kosten:

Vorgang MCU
get-miss 1,0
delete 2,0
increment 2,0
flush 100,0
stats 100,0

Beachten Sie, dass ein get-miss-Vorgang ein get ist, bei dem festgestellt wird, dass mit dem angegebenen Schlüssel kein Wert gespeichert ist.

Nächste Schritte

  • Informationen zum Konfigurieren, Überwachen und Verwenden von Memcache finden Sie unter Memcache verwenden