# 6. Mise en cache > Limites et configuration du cache dans les sections cache et proxy --- Index LLMS : [llms.txt](/fr/llms.txt) --- HAProxy fournit un cache, conçu pour effectuer le mise en mémoire tampon de petits objets (favicon, fichiers CSS...). Il s'agit d'un cache minimaliste, à faible maintenance, qui s'exécute en mémoire RAM. Le cache repose sur une zone mémoire partagée entre tous les threads, divisée en blocs de 1 ko. Si un objet n'est plus utilisé, il peut être supprimé afin de stocker un nouvel objet indépendamment de sa date d'expiration. Les objets les plus anciens sont supprimés en premier lorsque l'on tente d'allouer un nouvel objet. Le cache utilise un hachage de l'en-tête host et de l'URI comme clé. Il est possible de consulter l'état d'un cache à l'aide de la commande socket Unix « show cache » consultez la section [9.3](/fr/docs/haproxy/filters/#section-9-3) « Commandes socket Unix » du Guide d'administration pour plus de détails. Lorsqu'un objet est livré depuis le cache, le nom du serveur dans le journal est remplacé par "``". ## 6.1. Limitation {#section-6-1} Le cache ne stockera ni ne livrera d'objets dans ces cas : - Si la réponse n'est pas un 200 - Si la réponse contient un en-tête Vary et que l'option process-vary est désactivée, ou qu'un en-tête actuellement non géré est spécifié dans la valeur de Vary (seuls accept-encoding, referer et origin sont gérés pour l'instant) - Si la taille du Content-Length + celle des en-têtes est supérieure à "max-object-size" - Si la réponse n'est pas mise en cache - Si la réponse ne dispose pas de temps d'expiration explicite (directives Cache-Control s-maxage ou max-age) ou d'en-tête Expires, ni de validateur (en-têtes ETag ou Last-Modified) - Si l'option process-vary est activée et qu'il existe déjà max-secondary-entries entrées avec la même clé primaire que la réponse actuelle - Si l'option process-vary est activée et que la réponse possède une encodage inconnu (non mentionné dans ) tout en variant sur l'en-tête client accept-encoding - Si la requête n'est pas un GET - Si la version HTTP de la requête est inférieure à 1.1 - Si la requête contient un en-tête Authorization ## 6.2. Configuration {#section-6-2} Pour configurer un cache, vous devez définir une section de cache et l'utiliser dans un proxy à l'aide des actions http-request et http-response correspondantes. ### 6.2.1. Section cache {#section-6-2-1} **`cache `** ```haproxy cache ``` Déclare une section de cache, alloue une mémoire partagée nommée ``, la taille du cache est obligatoire (voir le mot-clé "total-max-size" ci-dessous). **`max-age `** ```haproxy max-age ``` Définir la durée maximale d'expiration. L'expiration est fixée à la valeur la plus faible entre les directives s-maxage ou max-age (dans cet ordre) présentes dans l'en-tête de réponse Cache-Control et cette valeur. La valeur par défaut est de 60 secondes, ce qui signifie que vous ne pouvez pas mettre en cache un objet plus de 60 secondes par défaut. **`max-object-size `** ```haproxy max-object-size ``` Définir la taille maximale des objets à mettre en cache. Ne doit pas dépasser la moitié de « total-max-size ». Si non définie, elle est égale à 1/256 de la taille du cache. Tous les objets dont la taille dépasse « max-object-size » ne seront pas mis en cache. **`max-secondary-entries `** ```haproxy max-secondary-entries ``` Définir le nombre maximal d'entrées secondaires simultanées ayant la même clé primaire dans le cache. Cela nécessite que le support de vary soit activé. Sa valeur par défaut est 10 et doit être un entier strictement positif. **`process-vary `** ```haproxy process-vary ``` Active ou désactive le traitement de l’en-tête Vary. Lorsqu’il est désactivé, une réponse contenant cet en-tête n’est jamais mise en cache. Lorsqu’il est activé, il faut calculer un hachage préliminaire pour un sous-ensemble des en-têtes de requête sur toutes les requêtes entrantes (ce qui peut entraîner une charge CPU) afin de construire une clé secondaire pour une requête donnée (voir RFC 7234#4.1). La clé secondaire est actuellement construite à partir du contenu des en-têtes « accept-encoding », « referer » et « origin ». Notez que les en-têtes « origin » et « referer » sont univalués selon la RFC, donc une requête comportant plusieurs occurrences de l’un ou l’autre doit être considérée comme malformée. Pour de telles requêtes, aucune clé secondaire n’est construite, et la réponse n’est jamais servie depuis le cache, afin de laisser le serveur décider de la manière de traiter la situation. La valeur par défaut est off (désactivé). **`total-max-size `** ```haproxy total-max-size ``` Définir la taille en mémoire RAM du cache en mégaoctets. Cette taille est divisée en blocs de 1 ko, utilisés par les entrées du cache. Sa valeur maximale est 4095. ### 6.2.2. Section proxy {#section-6-2-2} La section proxy utilisant le cache devra inclure l’action « cache-use » dans le jeu de règles « http-request » afin de rechercher l’objet demandé dans le cache, et l’action « cache-store » dans le jeu de règles « http-response » afin de stocker ou mettre à jour l’objet récupéré dans le cache. Chacune de ces actions peut éventuellement être soumise à des conditions. Par exemple, on peut décider de passer outre l’action « cache-use » pour un sous-répertoire donné connu pour ne pas être mis en cache, ou de passer outre l’action « cache-store » pour certains types de contenu connus pour être sans intérêt. Veuillez noter que la clé d’indexation du cache est calculée lors de l’action « cache-use », donc si cette action est omise, aucune tentative de mise à jour du cache ne sera effectuée sur le chemin de la réponse. Exemple : ```text backend bck1 mode http http-request cache-use foobar http-response cache-store foobar server srv1 127.0.0.1:80 cache foobar total-max-size 4 max-age 240 ``` --- Liens inverses : - [9. Filtres](/fr/docs/haproxy/filters/) - [4. Proxies](/fr/docs/haproxy/proxies/)