API Memcache pour les anciens services groupés

Cette page fournit un aperçu du service Memcache d'App Engine. Pour certaines tâches, les applications Web évolutives à hautes performances utilisent souvent un cache de données en mémoire distribué en plus ou à la place de solutions robustes de stockage permanent. App Engine fournit un service de cache mémoire à cette fin. Pour apprendre à configurer, surveiller et utiliser le service Memcache, consultez la page Utiliser Memcache.

Remarque : Le cache est global et partagé entre l'interface, le backend, et l'ensemble des services et des versions de l'application.

Cette API est compatible avec les environnements d'exécution de première génération et peut être utilisée lors de la mise à niveau vers des environnements d'exécution de deuxième génération correspondants. Si vous effectuez une mise à jour vers l'environnement d'exécution PHP 7+ d'App Engine, consultez le guide de migration pour en savoir plus sur les options de migration des anciens services groupés.

Quand utiliser un cache mémoire ?

Un cache mémoire peut servir à accélérer les requêtes courantes de magasin de données. Si de nombreuses requêtes envoient la même requête avec des paramètres identiques et que les modifications des résultats ne doivent pas nécessairement apparaître immédiatement sur le site Web, l'application peut mettre en cache les résultats dans le cache mémoire. Les requêtes suivantes peuvent consulter le cache mémoire, et n'effectuer la requête de datastore que si les résultats ne s'y trouvent pas ou sont arrivés à expiration. Les données de session, les préférences utilisateur et les autres données renvoyées par les requêtes pour les pages Web sont de bons candidats pour la mise en cache.

Memcache peut être utile pour d'autres valeurs temporaires. Toutefois, lorsque vous envisagez de stocker une valeur dans le cache mémoire exclusivement, sans sauvegarde dans un autre emplacement de stockage permanent, assurez-vous que votre application réagit convenablement en cas de soudaine indisponibilité de la valeur. Les valeurs dans le cache mémoire peuvent expirer à tout moment et avant la date limite d'expiration définie. Par exemple, si l'absence soudaine des données liées à une session d'utilisateur est susceptible de causer un dysfonctionnement de la session, il serait préférable de stocker ces données dans le datastore en plus du cache mémoire.

Niveaux de service

App Engine accepte deux niveaux du service Memcache :

• Memcache partagé : la valeur par défaut, gratuite pour les applications App Engine. La capacité de cache est fournie de la façon la plus optimale possible et soumise à la demande générale de toutes les applications App Engine utilisant le service Memcache partagé.

• Memcache dédié : fournit une capacité de cache fixe exclusivement allouée à votre application. Le service est facturé par taille de cache utilisé, au Go par heure, et nécessite d'activer la facturation. Grâce au contrôle de la taille du cache, votre application peut fonctionner de manière plus prévisible et avec moins de lectures dans un stockage durable plus coûteux.

Les deux niveaux de service Memcache utilisent la même API. Afin de configurer le service Memcache pour votre application, consultez la page Utiliser Memcache.

Remarque : Qu'il soit partagé ou dédié, le service Memcache n'est pas un système de stockage durable. Les clés peuvent être éliminées lorsque le cache est plein, conformément à la stratégie LRU du cache. Les modifications apportées à la configuration du cache ou les événements de maintenance du centre de données peuvent également vider entièrement ou partiellement le cache.

Le tableau suivant résume les différences entre les deux niveaux de service Memcache :

Caractéristique	Memcache dédié	Memcache partagé
Prix	0,06 $ (par Go et par heure)	Gratuit
Capacité	us-central 1 à 100 Go autres régions 1 à 20 Go	Pas de capacité garantie
Performances	Jusqu'à 10 000 lectures ou 5 000 écritures (exclusives) par seconde et par Go (éléments < 1 Ko). Pour en savoir plus, consultez la section Statistiques relatives au cache.	Sans garantie
Stockage durable	Non	Non
Contrat de niveau de service	Aucun	Aucun

L'utilisation de Memcache dédié est facturée par tranches de 15 minutes. Si vous ne payez pas en USD, les tarifs indiqués dans votre devise sur la page relative aux SKU de Cloud Platform s'appliquent.

Si votre application nécessite davantage de capacité Memcache, contactez notre équipe commerciale.

Limites

L'utilisation du service Memcache est soumise aux limitations ci-après :

• La taille maximale d'une valeur de données en cache est de 1 Mio (2^20 octets) moins la taille de la clé moins un espace système dépendant de l'implémentation, représentant environ 73 octets.
• Une clé ne peut pas dépasser 250 octets. Dans l'environnement d'exécution PHP, si vous essayez de définir Memcache avec une clé plus longue, l'appel génère une exception. (Le comportement est différent dans les autres environnements d'exécution.)
• Les opérations multiples par lot peuvent comporter un nombre illimité d'éléments. La taille totale de l'appel et la taille totale des données extraites ne doivent pas dépasser 32 mégaoctets.
• Une clé Memcache ne peut pas contenir d'octet nul.

Mise en œuvre PHP de Memcache

App Engine inclut des mises en œuvre des API standards Memcache et Memcached, qui appellent le service Memcache d'App Engine "en coulisses". Certaines fonctions font l'objet d'un stub, mais ne font rien car elles ne sont pas nécessaires dans le contexte d'une application App Engine. Par conséquent, les appels aux fonctions suivantes sont ignorés :

Fonctions qui font l'objet d'un stub dans l'API Memcache

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

Fonctions qui font l'objet d'un stub dans l'API Memcached

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

Exemple d'utilisation de l'API PHP Memcache dans App Engine :

appengine/php55/memcache/app.php

Afficher sur GitHub

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

Exemple d'utilisation de l'API PHP Memcached dans App Engine :

appengine/php55/memcache/app.php

Afficher sur GitHub

$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(),
]);

Modalités d'expiration des données mises en cache

Memcache contient des paires clé/valeur. Les paires en mémoire changent à tout moment à mesure que les éléments sont écrits et récupérés à partir du cache.

Par défaut, les valeurs stockées dans le cache mémoire sont conservées le plus longtemps possible. Elles peuvent être éliminées du cache lorsqu'une nouvelle valeur est ajoutée au cache et que celui-ci manque de mémoire. Lorsque des valeurs sont supprimées du fait de la saturation de la mémoire, les valeurs utilisées le moins récemment sont éliminées en premier.

L'application peut fournir une date d'expiration lors du stockage d'une valeur, soit sous la forme d'un nombre de secondes à partir de la date d'ajout de la valeur, soit sous la forme d'une date absolue dans une époque Unix future (un nombre de secondes à partir du 1er janvier 1970 à minuit). La valeur est supprimée au plus tard à cette date, bien qu'elle puisse être éliminée plus tôt pour d'autres raisons. L'incrémentation de la valeur stockée pour une clé existante ne met pas à jour sa date d'expiration.

Dans de rares cas, des valeurs peuvent également disparaître du cache avant l'expiration pour des raisons autres que la saturation de la mémoire. Bien que Memcache soit résilient aux pannes de serveur, les valeurs Memcache ne sont pas enregistrées sur le disque. Par conséquent, une défaillance du service peut rendre les valeurs indisponibles.

De manière générale, une application ne doit pas compter sur la disponibilité permanente d'une valeur mise en cache.

Vous pouvez effacer l'intégralité du cache d'une application via l'API ou dans la section Memcache de Google Cloud Console.

Remarque : La suppression effective des données de cache arrivées à expiration n'est pas gérée de façon très stricte. Un élément expiré est supprimé lorsque quelqu'un tente sans succès de le récupérer. Sinon, les données de cache arrivées à expiration sont éliminées du cache en fonction du comportement LRU du cache qui s'applique à tous les éléments, qu'ils soient actifs ou qu'ils aient expiré. Cela signifie donc que la taille du cache indiquée dans les statistiques peut inclure des éléments actifs et des éléments arrivés à expiration.

Statistiques relatives au cache

Opérations par seconde et par taille d'élément

Remarque : Ces informations ne s'appliquent qu'à Memcache dédié.

Memcache dédié est évalué en opérations par seconde et par Go, une opération correspondant à un accès individuel à un élément du cache, tel que get, set ou delete. Le taux varie en fonction de la taille des éléments, conformément au tableau ci-dessous. Tout dépassement peut entraîner une augmentation de la latence de l'API ou des erreurs.

Les tableaux suivants indiquent le nombre maximal d'opérations get-hit ou set exclusives et durables par Go de cache. Notez qu'une opération get-hit est un appel get qui détecte une valeur stockée avec la clé spécifiée et la renvoie.

Taille de l'élément (Ko)	Nombre maximal d'opérations get-hit/s	Nombre maximal d'opérations set/s
≤1	10 000	5 000
100	2 000	1 000
512	500	250

Une application configurée pour plusieurs Go de cache peut théoriquement atteindre un taux de fonctionnement global équivalant au nombre de Go multiplié par le taux par Go. Par exemple, une application configurée pour un cache de 5 Go peut atteindre 50 000 opérations Memcache/s sur des éléments de 1 Ko. Ce niveau exige une bonne répartition de la charge dans l'espace de clés Memcache.

Pour chaque modèle d'E/S, les limites répertoriées ci-dessus s'appliquent aux lectures ou aux écritures. Pour des lectures et écritures simultanées, les limites sont dégressives. Plus le nombre de lectures effectuées est élevé, moins le nombre d'écritures pouvant être effectuées est important, et inversement. Vous trouverez ci-dessous des exemples de limites d'IOPS pour les lectures et écritures simultanées de valeurs de 1 Ko par Go de cache :

IOPS de lecture	IOPS d'écriture
10 000	0
8000	1000
5000	2500
1000	4500
0	5000

Unités de calcul Memcache (MCU)

Remarque : Ces informations ne s'appliquent qu'à Memcache dédié.

Le débit de Memcache peut varier en fonction de la taille de l'élément auquel vous accédez et de l'opération que vous souhaitez effectuer sur cet élément. Vous pouvez globalement associer un coût approximatif aux opérations et estimer la capacité de trafic que vous pouvez attendre de Memcache dédié à l'aide d'une unité appelée "unité de calcul Memcache" (MCU). Le système des MCU est défini pour que vous puissiez vous attendre à un débit approximatif de 10 000 MCU par seconde et par Go de Memcache dédié. Google Cloud Console indique le nombre de MCU que votre application utilise actuellement.

Notez qu'une MCU fournit une estimation statistique approximative et qu'il ne s'agit pas d'une unité linéaire. Chaque opération de cache qui lit ou écrit une valeur a un coût MCU spécifique qui dépend de la taille de la valeur. La MCU d'une opération set dépend de la taille de la valeur : il s'agit de deux fois le coût d'une opération get-hit réussie.

Remarque : Le mode de calcul des unités de calcul Memcache (MCU) est sujet à modification.

Taille de l'élément de valeur (Ko)	Coût MCU pour get-hit	Coût MCU pour 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

Les opérations qui ne lisent ou n'écrivent pas de valeur ont un coût MCU fixe :

Opération	MCU
get-miss	1,0
delete	2,0
increment	2,0
flush	100,0
stats	100,0

Notez qu'une opération get-miss est une opération get qui indique qu'aucune valeur n'est stockée avec la clé spécifiée.

Bonnes pratiques

Voici quelques pratiques recommandées pour l'utilisation de Memcache :

• Gérer correctement les échecs de l'API Memcache. Les opérations Memcache peuvent échouer pour diverses raisons. Les applications doivent être conçues pour détecter les opérations ayant échoué, sans exposer ces erreurs aux utilisateurs finaux. Cette recommandation s'applique particulièrement aux opérations "set".

• Utilisez si possible la fonctionnalité de traitement par lot de l'API, en particulier pour les petits éléments. Vous améliorerez ainsi les performances et l'efficacité de votre application.

• Répartir la charge sur votre espace de clés Memcache. Le fait d'avoir un ou plusieurs petits éléments Memcache représentant un volume de trafic disproportionné empêche le scaling de votre application. Ces recommandations concernent aussi bien les opérations par seconde que la bande passante. Ce problème est généralement résolu en effectuant un partitionnement explicite des données.

  Par exemple, vous pouvez fractionner un compteur fréquemment mis à jour entre plusieurs clés, pour les relire et les additionner lorsque vous avez besoin d'un total. De la même manière, vous pouvez fractionner un élément de données de 500 Ko qui doit être lu sur chaque requête HTTP et le relire à l'aide d'un seul appel d'API par lots. (Une meilleure solution serait de mettre en cache la valeur dans la mémoire d'instance.) Pour Memcache dédié, le taux d'accès de pointe sur une clé unique est généralement inférieur d'un à deux ordres de grandeur au taux par Go.

Étapes suivantes

• Apprenez à configurer, surveiller et utiliser Memcache grâce à la page Utiliser Memcache.