Text: Choosing the Right Redis Eviction Policy

Votre cache Redis se remplit constamment en raison de sa limite de mémoire. Ce qui se passe ensuite dépend d’un paramètre unique que la plupart des utilisateurs laissent par défaut sans y prêter attention par la suite.

La politique de renvoi des immigrants.

Comprenez-le correctement, et Redis assure discrètement la sécurité de vos données les plus utilisées, maintient un taux de frappe élevé et garantit la réactivité de votre site même en cas de forte charge. Si vous vous trompez, Redis pourrait supprimer des clés importantes ou refuser des écritures, en fonction de la configuration. Dans SPanel, cette configuration est présentée sous forme de paramètre à ajuster plutôt que de devoir modifier manuellement le fichier de configuration de Redis.

Selon une étude de Deloitte, il a été constaté que même une légère amélioration de 0,1 seconde de la vitesse du site mobile peut entraîner une augmentation significative de 8,4% des taux de conversion dans le secteur de la vente au détail.

Résumons ce que signifie concrètement une politique d’expulsion de Redis, examinons chacun des huit éléments de manière simple, et déterminons celui qu’il serait judicieux d’appliquer.

Les utilisateurs de SPanel ont la possibilité de changer les paramètres d’expulsion de Redis directement depuis l’interface de gestion du cache Redis, sans avoir à passer par l’édition. Il leur suffit de se rendre dans le gestionnaire de cache Redis, où ils trouveront un menu déroulant intitulé “Mempolicy” sur le côté gauche de l’écran.

Quelle est la stratégie de suppression de Redis ?

Un principe d’éviction est appliqué par Redis afin de déterminer quelles clés seront supprimées lorsque la mémoire est pleine et qu’il est nécessaire d’écrire de nouvelles données. En d’autres termes, lorsque le cache est saturé, quelles données seront supprimées pour libérer de l’espace ?

Avant que l’expulsion puisse avoir lieu, deux conditions doivent être remplies.

1. Il y a une limite de mémoire en place. Redis ne supprime des données que lorsque cette limite est atteinte, définie par la valeur maxmemory. En l’absence de limite, Redis continuera à utiliser de la RAM indéfiniment, ce qui peut poser des problèmes pour le système d’exploitation.
2. Nouvelles idées nécessitent de la place. L’effacement se produit en réponse à la demande. Redis libère progressivement l’espace disponible à mesure que de nouveaux écrits arrivent et que la mémoire sature.

Voici la section qui transporte les individus vers le haut.

Hors de sa configuration d’origine, Redis open-source est livré avec la politique de “noeviction” par défaut, ce qui indique qu’il ne supprime rien et commence à refuser les écritures une fois que la mémoire est pleine. C’est une configuration sûre pour une base de données, mais inefficace pour un cache. Cela explique en partie pourquoi les environnements gérés préfèrent le changer.

Comparaison entre Volatile et Allkeys: Le premier embranchement sur le chemin.

Avant de pouvoir comprendre les huit politiques d’expulsion de Redis, il est nécessaire d’établir une distinction. Chaque politique opère selon l’une des deux perspectives suivantes :

• Les politiques d’Allkeys ont la capacité de supprimer n’importe quelle clé du cache, qu’elle soit assortie d’une date d’expiration ou non.
• Les clés sans expiration ne sont jamais supprimées, seules celles avec une durée de vie définie peuvent être effacées par les politiques volatiles.

Cette décision particulière, où chaque clé est considérée comme équitable, sauf si vous l’avez spécifiquement désignée comme temporaire, influence tout le reste.

Comment SPanel aborde-t-il cette question de manière distincte ?

Dans SPanel, chaque compte d’hébergement reçoit sa propre instance Redis dédiée avec une adresse de loopback privée, un mot de passe unique, une allocation de mémoire individuelle et une politique d’expulsion personnalisée. Par défaut, la configuration est allkeys-lfu avec une limite de mémoire de 256 Mo, ce qui convient généralement pour la plupart des charges de WordPress, WooCommerce et d’application-cache. Si vos besoins nécessitent une configuration différente, vous avez la possibilité de modifier la politique directement depuis le formulaire Redis Cache, sans avoir à éditer le fichier redis.conf via SSH.

Explication de toutes les huit politiques de suppression Redis.

Le logiciel Redis propose huit stratégies d’éviction, dont six sont des associations entre une portée (volatile ou allkeys) et une méthode (LRU, LFU ou aléatoire), ainsi que deux approches spécifiques : une basée sur TTL et la noeviction. Le tableau ci-dessous présente leur relation.

Ci-dessous se trouvent les responsabilités de chaque individu et la quantité de travail qui leur est appropriée.

Politique	Champ d ' application	Supprimer d ' abord	Meilleur pour
allkeys-lru	Chaque clé	Clé la plus récente	Mise en cache générale sans set de TTL
allkeys-lfu	Chaque clé	La clé la moins fréquemment consultée	La plupart des caches d’application (par défaut recommandé)
allkeys-random	Chaque clé	Une clé aléatoire	Accès uniforme où aucune clé n’est “hotter. ”
volatile-lru	touches TTL seulement	La clé TTL la plus récente	Mise en cache mixte + données de mémoire
volatile-lfu	touches TTL seulement	La clé TTL la moins fréquemment consultée	Données mixtes, cache à fréquence
volatile-random	touches TTL seulement	Une clé TTL aléatoire	Données mixtes, expulsion à faible consommation
volatile-ttl	touches TTL seulement	Clé la plus proche de l’expiration	Touches courtes, limiteurs de vitesse
noeviction	None	Rien – écrit l’erreur	Magasins persistants, jamais un cache pur

Les stratégies de remplacement de LRU (Least Recently Used) telles que volatile-lru et allkeys-lru.

Texto paraphrasé: L’algorithme LRU consiste à supprimer de la mémoire la clé qui n’a pas été utilisée depuis le plus longtemps, sous l’hypothèse que les données les plus anciennes et non sollicitées sont les moins susceptibles d’être nécessaires à nouveau. Cette stratégie est appliquée à l’ensemble du cache par allkeys-lru, tandis que volatile-lru se concentre uniquement sur les clés avec un TTL défini. LRU est un choix traditionnel et intuitif, étant pendant longtemps la seule option intelligente proposée par Redis.

Les politiques LFU (volatile-lfu, allkeys-lfu)

Le LFU, abréviation de moins fréquemment utilisé, est la mise à niveau que la plupart des caches recherchent. Contrairement à la méthode classique qui se demande “qu’est-ce qui a été le plus longtemps intouché?”, le LFU se demande “qu’est-ce qui se fait le moins souvent?” et agit en conséquence. Cette distinction est plus importante qu’il n’y paraît. Une clé peut être consultée des milliers de fois par heure, mais si elle est restée inactive pendant les dernières secondes, le LFU la conservera alors que la méthode LRU naïve pourrait la supprimer. Redis a introduit le LFU dans sa version 4.0 pour cette raison : il protège les clés actives, peu importe la fréquence d’utilisation.

Résumé: Les stratégies du hasard (volatile-randome, allkeys-random)

Paraphrase: Ce processus consiste à libérer de l’espace mémoire en supprimant de manière aléatoire une clé lorsque Redis atteint sa capacité maximale. Cette méthode ne laisse aucune trace ni impact significatif sur les performances. Cependant, elle est plus efficace lorsque l’accès aux clés est uniforme, ce qui n’est généralement pas le cas dans des situations réelles où certaines données sont plus fréquemment utilisées que d’autres.

La politique TTL (volatile-ttl) en matière de politique.

L’option “volatile-ttl” de Redis supprime la clé ayant le temps restant le plus court avant expiration, c’est-à-dire celle qui est la plus proche d’expirer de toute façon. Cette option ne prend en compte que les clés ayant un TTL défini. Cela permet à Redis de prioriser la suppression des clés sur le point d’expirer plutôt que de les conserver en fonction de l’accès. Cette fonctionnalité est utile lorsqu’on souhaite que Redis supprime en priorité les clés sur le point d’expirer, comme pour les limites de vitesse, les jetons temporaires ou les entrées de cache basées sur le temps.

Pas d’expulsion

La politique de non-éviction de Redis signifie qu’il ne supprime aucun élément. Lorsque la mémoire est pleine, Redis arrête d’accepter de nouvelles écritures qui nécessitent plus d’espace et renvoie une erreur de mémoire insuffisante. Les nouveaux écrits échouent tant que de l’espace n’est pas libéré. Continuez à travailler jusqu’à ce que de l’espace soit disponible.

Lorsque vous utilisez Redis pour stocker des données qui ne peuvent pas être facilement recréées, comme un compteur persistant ou une file d’attente, il est préférable d’utiliser la méthode “broken key”. Dans ce cas, il est important de savoir que la suppression silencieuse d’une clé est plus grave que le rejet d’une écriture. Votre application doit donc être capable de capturer et de gérer cette erreur de manière appropriée pour éviter que les utilisateurs ne rencontrent des échecs.

Message important de SPanel : SPanel Redis est principalement conçu comme un cache rapide et isolé pour un compte d’hébergement. Il s’agit d’une seule instance de Redis située sur le même serveur que le site, et SPanel ne propose pas la possibilité de clustering, de réplication, de haute disponibilité ou de persistance AOF pour Redis dans l’interface utilisateur. Si vous utilisez Redis pour des files d’attente, des compteurs ou d’autres données qui ne peuvent pas être facilement récupérées, assurez-vous que votre application peut gérer les contraintes de persistance et de disponibilité de Redis, ainsi que gérer correctement les erreurs d’écriture sans éviction.

Comparaison entre Allkeys-lfu et Allkeys-lru : Lequel devriez-vous choisir ?

Pour une mise en cache d’application standard, le meilleur choix est allkeys-lfu car il garde en mémoire les données les plus utilisées en fonction de leur fréquence d’accès, pas seulement de manière récente. Quant à allkeys-lru, il constitue une alternative fiable et bien comprise, presque aussi efficace et plus facile à comprendre.

La différence se réduit à un seul terme – la fréquence et la répétition.

• La méthode allkeys-lru protège les clés qui ont été récemment utilisées. Même si une clé a été accédée fréquemment toute la journée, elle peut être évacuée en dix secondes si de nouvelles clés prennent sa place.
• Le système allkeys-lfu offre une protection aux clés les plus fréquemment utilisées. Une clé spécifique reste “chaude” car Redis surveille la fréquence d’accès au fil du temps, et non seulement son horodatage de dernière utilisation.

Pour optimiser la mise en cache d’une base de données récurrente d’un site WordPress, d’un catalogue de commerce électronique ou de toute autre charge de travail contenant un ensemble défini d’objets populaires, la fréquence est un indicateur crucial. Ainsi, l’éviction basée sur la fréquence est la méthode privilégiée pour la plupart des caches d’application.

Paraphrase: Un système fiable : Les méthodes LRU et LFU de Redis sont des estimations qui impliquent l’échantillonnage d’un petit nombre de clés au lieu de numériser entièrement tous les espaces clés à chaque éviction. Cela permet de gagner en vitesse en sacrifiant une petite précision. Il est possible de ajuster ce processus d’échantillonnage, mais les paramètres par défaut conviennent à la plupart des sites dans la plupart des cas.

Comment sélectionner la politique d’éviction adéquate.

Pouvez-vous me donner un résumé succinct ?

Si vous utilisez un cache standard et que vous n’êtes pas certain, optez pour l’algorithme allkeys-lfu par défaut. C’est un choix raisonnable à moins que votre activité ne nécessite une autre option spécifique.

Utilisez ce schéma de flux pour déterminer rapidement où vous vous situez en répondant à environ trois questions.

Exprimer la logique à travers des mots en marchant.

1. Est-ce que Redis fonctionne comme un mécanisme de mise en cache ? Si les informations sont stockées ailleurs et peuvent être régénérées, que ce soit dans une base de données, une API ou une logique d’application, alors il est sûr de vider toutes les clés. Passez à l’étape 2. Si ce n’est pas le cas, vous utilisez Redis comme une base de données; passez à l’étape 3.
2. Est-ce que vos clés cachées ont une durée de vie définie ? Si vous avez spécifié des durées de vie pour toutes les clés et que vous souhaitez expirer uniquement ces clés, vous pouvez utiliser les options volatile-lru ou volatile-ttl. Si vos clés sont un mélange ou si aucune durée de vie n’a été définie, alors allkeys-lfu est la solution.
3. Est-ce que certaines de ces informations sont réellement indispensables ? Si c’est le cas, optez pour la stratégie volatile-lru afin que seules les clés de cache expirables soient retirées, laissant ainsi vos données intactes. Si rien ne peut être supprimé, la non-éviction est la seule option sûre, mais votre code devra gérer les erreurs d’écriture qui en découleront.

Message: Un indicateur vous montre si votre sélection est efficace : le nombre de clés expulsées. Si Redis éjecte fréquemment des éléments alors que votre cache est plein, il est probable que le cache soit trop petit ou mal configuré – et la solution est d’ajouter plus de mémoire, pas de changer de stratégie. Ces deux indicateurs sont disponibles dans les données statistiques de Redis, accessibles via tout bon tableau de bord de contrôle.

Surveillez l’exécution de votre politique de travail sur SPanel.

Une bonne politique d’expulsion est invisible quand elle fonctionne – donc la façon de confirmer qu’elle est de regarder les chiffres. Ouvrez la vue Redis stats dans votre compte SPanel et regardez deux figures : votre taux de succès (comment souvent les requêtes sont servies à partir de cache) et le nombre de clés expulsées (comment de nombreuses touches Redis est en jeu pour faire de la place). Si les évictions grimpent alors que vos vitesses de frappe, le cache est sous-dimensionné – augmenter la limite de mémoire du même écran plutôt que de changer les politiques. Si vous voulez voir exactement quelles clés votre application est la lecture et l’écriture, l’outil Monitor diffuse chaque commande Redis en temps réel pour une durée que vous définissez — utile pour confirmer votre plugin cache est en fait en utilisant Redis. Et après le déploiement d’un code qui modifie vos clés de cache, Flush Cache efface l’instance propre afin que l’application la reconstruise correctement. Ce sont des contrôles de libre-service, pas des billets de support.

Ajustement de la stratégie de suppression de votre configuration Redis

Sur la plupart des plateformes, modifier une règle d’expulsion implique de se connecter en SSH à un serveur, de modifier manuellement le fichier redis.conf, de s’assurer que la ligne maxmemory-policy est correctement configurée, et de redémarrer le service sans causer de dysfonctionnements. Pour une personne non spécialisée en développement qui gère un commerce actif, cela représente une demande de support technique stressante et une après-midi agitée.

Il n’est pas obligatoire.

Sur tous les plans d’hébergement VPS gérés par ScalaHosting, Redis est intégré directement, sans nécessité de l’ajouter en tant qu’option supplémentaire ou service premium. La fonction d’expulsion est facilement configurable via le Redis Cache Manager, un outil intégré à SPanel. En choisissant une politique d’expulsion, vous pouvez réaliser des économies, et SPanel se charge d’appliquer les modifications et de redémarrer le service Redis pour vous. Ainsi, vous n’aurez pas à modifier le fichier redis.conf ni à redémarrer manuellement Redis.

Sur un serveur autogéré classique, modifier la politique d’éviction de Redis implique de modifier le fichier redis.conf, de définir maxmemory-policy et de redémarrer Redis avec précaution. Dans SPanel, cette fonctionnalité est accessible via le formulaire de cache Redis. Sélectionnez la politique souhaitée, enregistrez les modifications, et SPanel se charge d’appliquer la nouvelle politique et de redémarrer le service Redis pour vous.

Certaines décisions ont déjà été prises en votre nom.

Nouvelle configuration disponible pour utiliser Redis avec une allocation mémoire de 256 Mo et l’option allkeys-lfu définie par défaut, ce qui convient à la plupart des sites sans nécessité de modification.

De plus, votre mémoire cache n’est pas partagée.

Chaque compte est associé à une instance isolée de Redis configurée avec une adresse privée et un mot de passe unique, ce qui empêche les clients d’accéder aux clés ou de lire les données des autres clients. En outre, le cache étant situé sur la même machine que votre site, les échanges de données entre l’application et le cache s’effectuent à la vitesse du réseau local. C’est ce qui rend le caching bénéfique pour un magasin WooCommerce occupé pendant une vente ou un site WordPress à fort trafic.

Il devrait être standard que l’hébergement accueillant les développeurs offre ce type de contrôle en libre-service, sur des infrastructures qui soutiennent déjà plus de 700 000 sites répartis dans 120 pays et plus.

Résumé: La conclusion ou l’élément principal.

La stratégie de rejet est un élément qui peut sembler gratuit pour obtenir de bons résultats, mais qui peut en réalité compromettre votre performance lorsqu’elle est mal appliquée. Pour la plupart des sites, la solution consiste à utiliser l’algorithme allkeys-lfu : conservez les éléments les plus utilisés, supprimez ceux qui sont moins sollicités et surveillez votre taux de réussite. Il est préférable de changer d’approche uniquement lorsque vos données l’indiquent.

Si vous souhaitez modifier ce réglage en utilisant un menu déroulant au lieu d’un fichier de configuration, et si Redis est intégré, isolé et correctement configuré dès le départ, un environnement entièrement géré simplifie la gestion du serveur pour vous.

Questions fréquemment posées

Question: Quelle est la politique par défaut de Redis en matière d’expulsion des données?

Réponse : Le Redis open-source par défaut utilise la politique noeviction, qui conserve les données en mémoire sans les expulser et rejette les nouvelles écritures une fois que la mémoire est pleine. Cependant, cette approche est plus adaptée à une base de données qu’à un cache. Par conséquent, les environnements gérés préfèrent généralement remplacer cette stratégie. Par exemple, Redis Cache Manager de SPanel déploie un Redis frais avec la politique allkeys-lfu, qui est plus efficace pour la mise en cache des applications.

Qu’arrive-t-il lorsque Redis dépasse la capacité de la mémoire disponible ?

Le système Redis met en œuvre la politique d’éviction que vous avez définie. Par exemple, avec une politique comme “allkeys-lfu”, il supprime les clés les moins importantes pour libérer de l’espace tout en conservant les demandes de service. En revanche, avec la politique “noeviction”, Redis cesse d’accepter les écritures qui nécessitent plus d’espace et renvoie une erreur de mémoire insuffisante, tandis que les lectures restent opérationnelles.

Question: Est-ce que l’algorithme LFU est plus efficace que l’algorithme LRU pour le cache?

La plupart des caches d’application utilisent LFU pour stocker les clés les plus fréquemment consultées, offrant ainsi une meilleure protection des données les plus sollicitées que LRU, qui se contente de suivre les clés touchées récemment. Cependant, LRU, plus simple, reste un choix fiable et fonctionne presque aussi efficacement dans de nombreuses situations réelles.

Question: Dans quels cas ne devrait-on pas utiliser l’algorithme allkeys-lfu ?

Ne pas activer l’algorithme allkeys-lfu dans Redis si des données essentielles ne peuvent pas être recréées. Si certaines clés sont à conserver en permanence, il est recommandé d’utiliser une politique de données volatiles et de définir des durées de vie uniquement pour les clés de cache temporaires. Si aucune clé ne peut être supprimée, optez pour l’option noeviction et veillez à ce que les applications gèrent les erreurs d’écriture correctement.

Question: À quel moment est-il approprié d’utiliser la fonction noeviction?

Utilisez l’option “noeviction” uniquement lorsqu’il s’agit de considérer Redis comme une base de données plutôt qu’un cache, c’est-à-dire pour des données qui sont cruciales et ne peuvent pas être facilement recréées en cas de suppression, telles qu’un compteur persistant ou une file d’attente. Dans le cas d’un cache classique, il est préférable d’éviter la noeviction, car la perte de données est plus grave que de supprimer des clés obsolètes. De plus, votre application doit être conçue pour gérer les problèmes de mémoire qu’elle pourrait engendrer.

Question: Est-ce que je devrais modifier la politique d’éviction par moi-même?

En général, il est recommandé d’utiliser allkeys-lfu comme point de départ pour la plupart des besoins de cache, car il est préconfiguré pour être déployé rapidement sur SPanel. Vous pouvez le modifier si votre cas nécessite des spécificités, comme la combinaison de données de cache et de sauvegarde, ou la gestion des expirations de clés de façon limitée.

Question : Est-il possible de changer la politique d’éviction sans altérer les fichiers de configuration ?

Réponse: Oui, sur les plateformes où il est affiché dans le panneau. Le Redis Cache Manager de ScalaHosting propose une liste complète de huit politiques dans un menu déroulant ; vous en sélectionnez une, enregistrez, et SPanel l’applique à votre Redis en cours avant de redémarrer le service. Vous n’avez pas besoin de modifier le fichier redis.conf ni d’utiliser la ligne de commande.