# Wat is Django `LocMemCache` (lokale geheugen cache)?

![Robot data storage image](/media/editor_temp/6/62743df3-4837-47d2-b16a-a458240f5629.png)

`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 de **actieve Django-proces**
* **Delen:** **Niet gedeeld buiten het proces (per-process)**
* **Eigenschap:** **Thread‑veilig**

---

## Welke problemen lost het op? {#sec-d5ce9d49504b}

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 {#sec-5812aa71ede8}

### 1) “Per‑process” cache (belangrijkste) {#sec-82e1553d2867}

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” {#sec-b592565e73f5}

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

### 3) Cache wordt gewist bij herstart {#sec-56535f9324da}

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

---

## Hoe instellen? {#sec-ed6e3fa738df}

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

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

De voorbeeldconfiguratie in de officiële documentatie is hierboven. `LOCATION` fungeert als een identifier om cache‑instanties te onderscheiden.

---

## Voordelen {#sec-38c232e71484}

* **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 {#sec-070a65a9d9f5}

* **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? {#sec-99e7489ed70c}

* 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.