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.
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.
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é |
|
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 |
| SLA | 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 des codes SKU Cloud Platform s'appliquent.
Si votre application nécessite davantage de capacité Memcache, contactez notre équipe commerciale.
Limites
Les limites suivantes s'appliquent à l'utilisation du service Memcache :
- La taille maximale d'une valeur de données en cache est de 1 Mo (10^6 octets).
- Une clé ne peut pas dépasser 250 octets. Dans l'environnement d'exécution Python, les clés qui sont des chaînes de plus de 250 octets sont hachées.
- 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 un octet nul.
Recommandations et bonnes pratiques
Lorsque vous utilisez Memcache, nous vous recommandons de concevoir vos applications pour :
Gérer le cas où une valeur mise en cache n'est pas toujours disponible
- Memcache n'est pas un stockage durable. Selon les règles d'éviction, les clés sont éliminées lorsque le cache est plein. 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.
- Memcache peut rencontrer une indisponibilité temporaire. Les opérations Memcache peuvent échouer pour diverses raisons, y compris à cause de modifications apportées à la configuration du cache ou d'événements de maintenance du centre de données. 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".
Utiliser si possible la fonctionnalité de traitement par lot de l'API
- Procéder ainsi augmente les performances et l'efficacité de votre application, en particulier pour les petits éléments.
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.
Conserver vos propres clés afin de récupérer les valeurs du cache.
- Memcache ne propose pas de méthode permettant de lister les clés. En raison de sa nature, il n'est pas possible de répertorier les clés sans interrompre le cache. En outre, certains langages, tels que Python, hachent les clés longues et les clés d'origine ne sont connues que par l'application.
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.
Statistiques relatives au cache
Opérations par seconde et par taille d'élément
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)
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é. La console Google Cloud 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.
| 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 un appel get qui indique qu'aucune valeur n'est stockée avec la clé spécifiée.
Fonctionnalité Compare-And-Set
La fonctionnalité Compare-And-Set permet à plusieurs requêtes traitées simultanément de mettre à jour la valeur d'une même clé Memcache de manière atomique, ce qui empêche les conditions de concurrence.
Principaux composants logiques de la fonctionnalité Compare-And-Set
Si vous mettez à jour la valeur d'une clé Memcache susceptible de recevoir d'autres requêtes d'écriture simultanées, vous devez utiliser l'objet Memcache Client, qui stocke certaines informations d'état utilisées par les méthodes compatibles avec la fonctionnalité Compare-And-Set. Vous ne pouvez pas utiliser les fonctions Memcache get() ou set(), car elles sont sans état. La classe Client n'est pas sécurisée. Par conséquent, vous ne devez pas utiliser le même objet Client dans plusieurs threads.
Lorsque vous récupérez des clés, vous devez utiliser les méthodes Client de Memcache qui acceptent la comparaison et la définition : gets() ou get_multi() avec le paramètre for_cas défini sur True.
Lorsque vous mettez à jour une clé, vous devez utiliser les méthodes Client de Memcache qui acceptent la comparaison et la définition : cas() ou cas_multi().
L'autre principal composant logique est le service Memcache d'App Engine et son comportement vis-à-vis de la fonctionnalité Compare-And-Set. Le service Memcache d'App Engine se comporte de manière atomique. Ainsi, lorsque deux requêtes simultanées (pour le même ID application) utilisent Memcache, elles sont envoyées à la même instance de service Memcache. En outre, le service Memcache dispose d'un verrouillage interne suffisant pour que des requêtes simultanées associées à une même clé soient correctement sérialisées. Cela signifie par exemple que deux requêtes cas() associées à une même clé ne s'exécutent pas en parallèle. Le service traite en effet la première requête entrante jusqu'à ce qu'elle soit terminée (et que la valeur et l'horodatage soient mis à jour) avant de commencer à traiter la deuxième requête.
Pour découvrir comment utiliser la fonctionnalité Compare-And-Set dans l'environnement Python, consultez la page Traiter les écritures simultanées.
Étapes suivantes
- Apprenez à configurer, surveiller et utiliser Memcache grâce à la page Utiliser Memcache.
- Consultez des exemples Memcache.