Wat is Django LocMemCache (lokale geheugen cache)?

Robot data storage image

LocMemCache is een lokale geheugen (Local-memory) cache backend die door Django wordt geleverd. Als je geen aparte cacheconfiguratie opgeeft, gebruikt Django standaard deze lokale geheugen cache. Het is een eenvoudige oplossing voor apps zonder gedeeld geheugen, ideaal voor snelle tests op een ontwikkelserver voordat je Redis instelt.

Samenvatting van kenmerken

  • Opslaglocatie: RAM van het actieve Django-proces
  • Delen: Niet gedeeld buiten het proces (per-process)
  • Eigenschap: Thread‑veilig

Welke problemen lost het op?

Caches slaan “duurzaam berekende/gevraagde resultaten” tijdelijk op, zodat ze bij volgende verzoeken hergebruikt kunnen worden.

Bijvoorbeeld, als je vaak gebruikte waarden uit de database in de cache plaatst:

  • Eerste verzoek: DB‑query → resultaat in cache opslaan
  • Volgende verzoeken: direct uit cache teruggeven (snel)

LocMemCache slaat deze cache direct in het geheugen van je eigen proces zonder externe systemen (Redis/Memcached, etc.).

Drie kernaspecten van de werking

1) “Per‑process” cache (belangrijkste)

De Django‑documentatie zegt duidelijk: de lokale geheugen cache is per-process. Dus:

  • 4 Gunicorn‑werkers → 4 caches
  • 2 servers → Elke server heeft een eigen cache

Er is geen gedeelde cache tussen processen of servers.

2) “Thread‑veilig”

Binnen één proces kunnen meerdere threads veilig tegelijkertijd toegang krijgen.

3) Cache wordt gewist bij herstart

Omdat het alleen in het geheugen staat, wordt de cache gereset wanneer het proces opnieuw start.

Hoe instellen?

In settings.py geef je in CACHES de BACKEND op.

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.locmem.LocMemCache",
        "LOCATION": "unique-snowflake",
    }
}

De voorbeeldconfiguratie in de officiële documentatie is hierboven. LOCATION dient als identifier om verschillende cache-instanties van elkaar te onderscheiden.

Voordelen

  • Weinig configuratie: geen externe cache‑server nodig
  • Snel: toegang tot dezelfde proces‑RAM, lage latentie
  • Handig voor ontwikkeling/testen: “cache‑concept” zonder extra afhankelijkheden

Nadelen en aandachtspunten

  • Cache wordt opgesplitst in multi‑process/ multi‑server → kan lijken alsof de cache niet werkt
  • Onvoorspelbaar in productie: bij verkeer dat over meerdere processen wordt verdeeld, kan de hit‑rate dalen
  • Niet aanbevolen als sessie‑opslag: Django‑sessie‑documentatie waarschuwt dat lokale geheugen cache niet langdurig blijft en niet veilig is voor multi‑process

Wanneer is het geschikt?

  • Lokale ontwikkelomgeving
  • Een enkel proces (of “geen gedeelde cache nodig”)
  • Functie‑verificatie / testen (minimale externe afhankelijkheid)

Omgekeerd, als je meerdere processen / servers hebt die dezelfde cache moeten delen, is het gebruikelijker om een gedeelde cache zoals Redis of Memcached te overwegen.