Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Konfiguration von serverseitigem Caching und API Nutzlastkomprimierung in AWS AppSync
AWS AppSync Die serverseitigen Funktionen zum Zwischenspeichern von Daten stellen Daten in einem In-Memory-Cache mit hoher Geschwindigkeit zur Verfügung, wodurch die Leistung verbessert und die Latenz verringert wird. Dies reduziert die Notwendigkeit, direkt auf Datenquellen zuzugreifen. Caching ist sowohl für Unit- als auch für Pipeline-Resolver verfügbar.
AWS AppSync ermöglicht es Ihnen auch, API Antworten zu komprimieren, sodass Nutzdateninhalte schneller geladen und heruntergeladen werden. Dies reduziert potenziell die Belastung Ihrer Anwendungen und senkt möglicherweise auch Ihre Datenübertragungsgebühren. Das Komprimierungsverhalten ist konfigurierbar und kann nach eigenem Ermessen festgelegt werden.
In diesem Abschnitt finden Sie Hilfe bei der Definition des gewünschten Verhaltens von serverseitigem Caching und Komprimierung in Ihrem. AWS AppSync API
Instance-Typen
AWS AppSync hostet Amazon ElastiCache (RedisOSS) -Instances in demselben AWS Konto und derselben AWS Region wie Ihre AWS AppSync API.
Die folgenden Instance-Typen ElastiCache (RedisOSS) sind verfügbar:
- small
-
1 VCPU, 1,5 GiBRAM, geringe bis mäßige Netzwerkleistung
- Medium
-
2 VCPU, 3 GiBRAM, geringe bis mäßige Netzwerkleistung
- large
-
2 VCPU, 12,3 GiBRAM, bis zu 10 Gigabit Netzwerkleistung
- xlarge
-
4 VCPU, 25,05 GiBRAM, bis zu 10 Gigabit Netzwerkleistung
- 2xlarge
-
8 VCPU, 50,47 GiBRAM, bis zu 10 Gigabit Netzwerkleistung
- 4xlarge
-
16 VCPU, 101,38 GiBRAM, bis zu 10 Gigabit Netzwerkleistung
- 8xlarge
-
32 VCPU, 203,26 GiBRAM, 10-Gigabit-Netzwerkleistung (nicht in allen Regionen verfügbar)
- 12xlarge
-
48 VCPU, 317,77 GiBRAM, 10 Gigabit Netzwerkleistung
Anmerkung
In der Vergangenheit haben Sie einen bestimmten Instance-Typ angegeben (z. B.). t2.medium
Seit Juli 2020 sind diese älteren Instanztypen weiterhin verfügbar, ihre Verwendung ist jedoch veraltet und es wird davon abgeraten. Wir empfehlen, die hier beschriebenen generischen Instanztypen zu verwenden.
Caching-Verhalten
Im Folgenden sind die Verhaltensweisen im Zusammenhang mit dem Caching aufgeführt:
- None
-
Keine serverseitige Zwischenspeicherung.
- Vollständige Zwischenspeicherung von Anforderungen
-
Wenn sich die Daten nicht im Cache befinden, werden sie aus der Datenquelle abgerufen und füllen den Cache bis zum Ablauf von Time to Live (TTL). Alle nachfolgenden Anfragen an Sie API werden aus dem Cache zurückgegeben. Das bedeutet, dass Datenquellen nicht direkt kontaktiert werden, es sei denn, sie TTL laufen ab. In dieser Einstellung verwenden wir den Inhalt der
context.arguments
undcontext.identity
-Maps als Caching-Schlüssel. - Zwischenspeicherung pro Resolver
-
Bei dieser Einstellung muss jeder Resolver explizit aktiviert werden, damit er Antworten zwischenspeichern kann. Sie können einen Wert angeben TTL und Schlüssel auf dem Resolver zwischenspeichern. Bei den Caching-Schlüsseln, die Sie angeben können, handelt es sich um die Zuordnungen
context.arguments
context.source
context.identity
, und und/oder Zeichenkettenfelder der obersten Ebene aus diesen Zuordnungen. Der TTL Wert ist obligatorisch, aber die Caching-Schlüssel sind optional. Wenn Sie keine Caching-Schlüssel angeben, sind die Standardwerte der Inhalt der Zuordnungencontext.arguments
context.source
, und.context.identity
Sie könnten beispielsweise die folgenden Kombinationen verwenden:
-
context.arguments und context.source
-
context.arguments und context.identity.sub
-
context.arguments.id oder context.arguments. InputType.id
-
context.source.id und context.identity.sub
-
context.identity.claims.username
Wenn Sie nur einen Schlüssel TTL und keine Caching-Schlüssel angeben, verhält sich der Resolver genauso wie beim vollständigen Zwischenspeichern von Anfragen.
-
- Gültigkeitsdauer zwischenspeichern
-
Diese Einstellung legt fest, wie lange zwischengespeicherte Einträge im Speicher gespeichert werden sollen. Das Maximum TTL ist 3.600 Sekunden (1 Stunde). Danach werden Einträge automatisch gelöscht.
Cache-Verschlüsselung
Die Cache-Verschlüsselung gibt es in den folgenden zwei Varianten. Diese ähneln den Einstellungen, die ElastiCache (RedisOSS) zulässt. Sie können die Verschlüsselungseinstellungen nur aktivieren, wenn Sie das Caching für Ihren zum ersten Mal aktivieren. AWS AppSync API
-
Verschlüsselung bei der Übertragung — Anfragen zwischen AWS AppSync dem Cache und Datenquellen (außer unsicheren HTTP Datenquellen) werden auf Netzwerkebene verschlüsselt. Da zum Verschlüsseln und Entschlüsseln der Daten an den Endpunkten einige Verarbeitungsvorgänge erforderlich sind, kann die Verschlüsselung während der Übertragung die Leistung beeinträchtigen.
-
Verschlüsselung im Ruhezustand — Daten, die während Swap-Vorgängen aus dem Speicher auf der Festplatte gespeichert werden, werden in der Cache-Instance verschlüsselt. Diese Einstellung wirkt sich auch auf die Leistung aus.
Um Cache-Einträge für ungültig zu erklären, können Sie entweder mit der AWS AppSync Konsole oder mit AWS Command Line Interface ()AWS CLI einen API Flush-Cache-Aufruf ausführen.
Weitere Informationen finden Sie in der Referenz zum ApiCacheDatentyp. AWS AppSync API
Räumung des Caches
Wenn Sie AWS AppSync das serverseitige Caching einrichten, können Sie ein Maximum konfigurieren. TTL Dieser Wert definiert die Zeitspanne, für die zwischengespeicherte Einträge im Speicher gespeichert werden. In Situationen, in denen Sie bestimmte Einträge aus Ihrem Cache entfernen müssen, können Sie AWS AppSync das evictFromApiCache
Erweiterungsprogramm in der Anfrage oder Antwort Ihres Resolvers verwenden. (Zum Beispiel, wenn sich Ihre Daten in Ihren Datenquellen geändert haben und Ihr Cache-Eintrag jetzt veraltet ist.) Um ein Element aus dem Cache zu entfernen, müssen Sie seinen Schlüssel kennen. Wenn Sie Elemente dynamisch entfernen müssen, empfehlen wir daher, das Zwischenspeichern pro Resolver zu verwenden und explizit einen Schlüssel zu definieren, mit dem Einträge zu Ihrem Cache hinzugefügt werden.
Einen Cache-Eintrag löschen
Verwenden Sie das Erweiterungsprogramm, um ein Element aus dem Cache zu entfernen. evictFromApiCache
Geben Sie den Typ- und Feldnamen an und stellen Sie dann ein Objekt mit Schlüsselwertelementen bereit, um den Schlüssel für den Eintrag zu erstellen, den Sie entfernen möchten. Im Objekt steht jeder Schlüssel für einen gültigen Eintrag aus dem context
Objekt, das in der Liste des zwischengespeicherten Resolvers verwendet wird. cachingKey
Jeder Wert ist der tatsächliche Wert, der verwendet wurde, um den Wert des Schlüssels zu ermitteln. Sie müssen die Elemente im Objekt in derselben Reihenfolge platzieren wie die Caching-Schlüssel in der Liste des zwischengespeicherten Resolvers. cachingKey
Sehen Sie sich zum Beispiel das folgende Schema an:
type Note { id: ID! title: String content: String! } type Query { getNote(id: ID!): Note } type Mutation { updateNote(id: ID!, content: String!): Note }
In diesem Beispiel können Sie das Caching pro Resolver aktivieren und es dann für die Abfrage aktivieren. getNote
Anschließend können Sie den Caching-Schlüssel so konfigurieren, dass er aus besteht. [context.arguments.id]
Wenn Sie versuchenNote
, einen abzurufen, um den Cache-Schlüssel zu erstellen, AWS AppSync führt er mithilfe des id
Arguments der Abfrage eine Suche in seinem serverseitigen Cache durch. getNote
Wenn Sie eine aktualisierenNote
, müssen Sie den Eintrag für die spezifische Notiz entfernen, um sicherzustellen, dass sie bei der nächsten Anforderung aus der Backend-Datenquelle abgerufen wird. Dazu müssen Sie einen Request-Handler erstellen.
Das folgende Beispiel zeigt eine Möglichkeit, die Räumung mit dieser Methode zu handhaben:
import { util, Context } from '@aws-appsync/utils'; import { update } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { extensions.evictFromApiCache('Query', 'getNote', { 'ctx.args.id': ctx.args.id }); return update({ key: { id: ctx.args.id }, update: { context: ctx.args.content } }); } export const response = (ctx) => ctx.result;
Alternativ können Sie die Räumung auch im Response-Handler abwickeln.
Wenn die updateNote
Mutation verarbeitet ist, wird AWS AppSync versucht, den Eintrag zu entfernen. Wenn ein Eintrag erfolgreich gelöscht wurde, enthält die Antwort einen apiCacheEntriesDeleted
Wert im extensions
Objekt, der angibt, wie viele Einträge gelöscht wurden:
"extensions": { "apiCacheEntriesDeleted": 1}
Löschen eines Cache-Eintrags auf der Grundlage seiner Identität
Sie können Caching-Schlüssel auf der Grundlage mehrerer Werte aus dem Objekt erstellen. context
Nehmen wir zum Beispiel das folgende Schema, das Amazon Cognito Cognito-Benutzerpools als Standard-Authentifizierungsmodus verwendet und von einer Amazon DynamoDB DynamoDB-Datenquelle unterstützt wird:
type Note { id: ID! # a slug; e.g.: "my-first-note-on-graphql" title: String content: String! } type Query { getNote(id: ID!): Note } type Mutation { updateNote(id: ID!, content: String!): Note }
Die Note
Objekttypen werden in einer DynamoDB-Tabelle gespeichert. Die Tabelle hat einen zusammengesetzten Schlüssel, der den Amazon Cognito Cognito-Benutzernamen als Primärschlüssel und den id
(einen Slug) von Note
als Partitionsschlüssel verwendet. Dies ist ein Mehrmandantensystem, das es mehreren Benutzern ermöglicht, ihre privaten Note
Objekte zu hosten und zu aktualisieren, die niemals gemeinsam genutzt werden.
Da es sich um ein leseintensives System handelt, wird die getNote
Abfrage per Resolver-Caching zwischengespeichert, wobei sich der Caching-Schlüssel aus folgenden Komponenten zusammensetzt: [context.identity.username, context.arguments.id]
Wenn a aktualisiert Note
wird, können Sie den entsprechenden Eintrag löschen. Note
Sie müssen die Komponenten dem Objekt in derselben Reihenfolge hinzufügen, in der sie in der Liste Ihres Resolvers angegeben sind. cachingKeys
Das folgende Beispiel zeigt dies:
import { util, Context } from '@aws-appsync/utils'; import { update } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { extensions.evictFromApiCache('Query', 'getNote', { 'ctx.identity.username': ctx.identity.username, 'ctx.args.id': ctx.args.id, }); return update({ key: { id: ctx.args.id }, update: { context: ctx.args.content } }); } export const response = (ctx) => ctx.result;
Ein Backend-System kann den Eintrag auch aktualisieren Note
und entfernen. Nehmen wir zum Beispiel diese Mutation:
type Mutation { updateNoteFromBackend(id: ID!, content: String!, username: ID!): Note @aws_iam }
Sie können den Eintrag entfernen, aber die Komponenten des Caching-Schlüssels zum Objekt hinzufügen. cachingKeys
Im folgenden Beispiel erfolgt die Räumung in der Antwort des Resolvers:
import { util, Context } from '@aws-appsync/utils'; import { update } from '@aws-appsync/utils/dynamodb'; export function request(ctx) { return update({ key: { id: ctx.args.id }, update: { context: ctx.args.content } }); } export function response(ctx) { extensions.evictFromApiCache('Query', 'getNote', { 'ctx.identity.username': ctx.args.username, 'ctx.args.id': ctx.args.id, }); return ctx.result; }
In Fällen, in denen Ihre Backend-Daten außerhalb von aktualisiert wurden AWS AppSync, können Sie ein Element aus dem Cache entfernen, indem Sie eine Mutation aufrufen, die eine Datenquelle verwendet. NONE
Antworten werden komprimiert API
AWS AppSync ermöglicht es Clients, komprimierte Payloads anzufordern. Auf Anfrage werden API Antworten komprimiert und als Antwort auf Anfragen zurückgegeben, die angeben, dass komprimierter Inhalt bevorzugt wird. Komprimierte API Antworten werden schneller geladen, Inhalte werden schneller heruntergeladen und Ihre Datenübertragungsgebühren können ebenfalls reduziert werden.
Anmerkung
Die Komprimierung ist für alle neuen Versionen verfügbar, die nach dem 1. Juni 2020 APIs erstellt wurden.
AWS AppSync komprimiert Objekte nach bestem Wissen. In seltenen Fällen AWS AppSync kann die Komprimierung aufgrund einer Vielzahl von Faktoren, einschließlich der aktuellen Kapazität, übersprungen werden.
AWS AppSync kann GraphQL-Abfrage-Payloadgrößen zwischen 1.000 und 10.000.000 Byte komprimieren. Um die Komprimierung zu aktivieren, muss ein Client den Accept-Encoding
Header mit dem Wert senden. gzip
Die Komprimierung kann überprüft werden, indem der Wert des Content-Encoding
Headers in der Antwort (gzip
) überprüft wird.
Der Abfrage-Explorer in der AWS AppSync Konsole legt standardmäßig automatisch den Header-Wert in der Anfrage fest. Wenn Sie eine Abfrage ausführen, die eine ausreichend große Antwort hat, kann die Komprimierung mithilfe der Entwicklertools Ihres Browsers bestätigt werden.