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 |
| 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 des codes SKU 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, soit environ 73 octets.
- Une clé ne peut pas dépasser 250 octets. Dans l'environnement d'exécution Java, les clés qui sont des objets ou des chaînes de plus de 250 octets seront hachées. (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 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. Conformément aux règles d'éviction, les clés sont supprimé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
- Vous améliorerez ainsi 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.
Conservez vos propres clés afin de récupérer les valeurs du cache.
- Memcache ne fournit pas de méthode permettant de répertorier 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.
API disponibles
Le cache mémoire d'App Engine prend en charge deux interfaces : une API Memcache de bas niveau et la spécification JCache. Les sections suivantes fournissent plus d'informations sur chaque interface.
API de bas niveau
L'API Memcache de bas niveau prend en charge davantage de fonctionnalités que JCache. Voici quelques exemples :
- Atomiquement incrémenter et décrémenter les valeurs de compteur d'entiers.
- Afficher davantage de statistiques sur le cache, telles que le temps écoulé depuis l'accès à l'entrée la moins récemment utilisée et la taille totale de tous les objets du cache.
- Vérifier et définir les opérations pour stocker des données de manière conditionnelle.
- Effectuer les opérations Memcache de manière asynchrone, à l'aide de AsyncMemcacheService.
L'API de bas niveau fournit MemcacheService et AsyncMemcacheService pour accéder au service Memcache. Cette API est plus riche que celle fournie par JCache.
Consultez Exemples Memcache pour des exemples d'utilisation synchrone et asynchrone de l'API Memcache de bas niveau.
JCache
Le SDK Java App Engine prend en charge l'API JCache. JCache fournit une interface semblable à une carte pour les données en cache. Vous pouvez stocker des valeurs dans le cache et les récupérer à l'aide de clés. Les clés et valeurs peuvent appartenir à n'importe quel type ou classe sérialisable. Pour plus de détails, voir Utiliser Memcache.
Fonctions JCache non prises en charge
JCache ne prend pas en charge les fonctionnalités suivantes :
- L'API d'écoute JCache est partiellement prise en charge pour les écouteurs pouvant s'exécuter lors du traitement d'un appel d'API d'une application, tels que les écouteurs
onPutetonRemove. Les écouteurs tels queonEvictqui nécessitent un traitement en arrière-plan ne sont pas pris en charge. - Une application peut vérifier si le cache contient une clé donnée, mais il lui est impossible de contrôler si le cache comporte une valeur spécifique (la méthode
containsValue()n'est pas prise en charge). - Une application ne peut pas vider le contenu des clés ou des valeurs du cache.
- Une application ne peut pas redéfinir manuellement les statistiques relatives au cache.
- La méthode
put()ne renvoie pas la valeur précédente connue d'une clé. Elle retourne toujours la valeurnull.
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é. 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.
| 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.
Étapes suivantes
- Apprenez à configurer, surveiller et utiliser Memcache grâce à la page Utiliser Memcache.