# Was ist Django `LocMemCache` (lokaler Speicher-Cache)?

![Roboter-Datenlager](/media/editor_temp/6/62743df3-4837-47d2-b16a-a458240f5629.png)

`LocMemCache` ist das **lokale Speicher-Cache-Backend** von Django. Wenn keine speziellen Cache-Einstellungen vorgenommen werden, nutzt Django standardmäßig diesen lokalen Speicher-Cache. Er eignet sich für Anwendungen mit relativ einfacher Struktur, die ohne Speicherfreigabe schnell und unkompliziert laufen sollen, oder für Entwicklungsserver, um vor einer Redis-Installation rasch zu testen.

## Kurzfassung der Eigenschaften {#sec-9f5f41df53f7}

- **Speicherort:** RAM des aktuell laufenden **Django-Prozesses**  
- **Freigabeumfang:** **Nicht prozessübergreifend geteilt** (per‑process)  
- **Eigenschaft:** **Thread‑sicher**

---

## Welche Probleme löst das? {#sec-1125dc27671c}

Caches speichern „teure Berechnungen/Abfragen“ kurzzeitig, damit sie bei der nächsten Anfrage wiederverwendet werden können.

Beispiel: Häufig abgefragte Werte aus der Datenbank in den Cache legen

1. Erste Anfrage: DB‑Abfrage → Ergebnis im Cache speichern  
2. Folgende Anfragen: sofort aus dem Cache zurückgeben (schnell)

`LocMemCache` speichert diesen Cache **ohne externes System (Redis/Memcached usw.)** direkt im Speicher des eigenen Prozesses.

---

## Kernmechanismen – drei wesentliche Punkte {#sec-ec34cec153c4}

### 1) Prozess‑basiert (am wichtigsten) {#sec-6a34b3d26795}

Django‑Dokumentation schreibt eindeutig: Der lokale Speicher‑Cache ist **per‑process**. Das bedeutet:

- 4 Gunicorn‑Worker → **4 separate Caches**  
- 2 Server → **jeweils eigener Cache**

Daher ist **keine Cache‑Freigabe zwischen Prozessen/Servern** möglich.

### 2) Thread‑sicher {#sec-96df850d13a2}

Innerhalb eines Prozesses können mehrere Threads gleichzeitig darauf zugreifen, ohne dass es zu Problemen kommt.

### 3) Beim Neustart verschwindet der Cache {#sec-4e25e34603d5}

Da er ausschließlich im Speicher liegt, wird der Cache beim Neustart des Prozesses ebenfalls zurückgesetzt.

---

## Konfiguration {#sec-a888c50cc9fd}

In `settings.py` wird `CACHES` mit dem `BACKEND` definiert.

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

Die Beispielkonfiguration stammt aus der offiziellen Dokumentation; `LOCATION` dient als Identifikator, um Cache‑Instanzen zu unterscheiden.

---

## Vorteile {#sec-0d979cd0b984}

- **Fast keine Konfiguration nötig**: Kein externer Cache‑Server erforderlich  
- **Schnell**: Zugriff im selben Prozess‑Speicher → geringe Latenz  
- **Entwicklungs‑/Testfreundlich**: „Cache‑Konzept“ ohne externe Abhängigkeiten ausprobieren

---

## Nachteile und Vorsichtsmaßnahmen {#sec-de98bad237ea}

- **Cache‑Fragmentierung bei Multi‑Prozess/Mehr‑Server** → kann den Eindruck erwecken, dass der Cache nicht funktioniert  
- **Unvorhersehbare Leistung in Produktion**: Bei verteiltem Traffic kann die Cache‑Hit‑Rate sinken  
- **Nicht empfohlen als Sitzungs‑Speicher**: Django‑Sitzungsdokumentation warnt, dass der lokale Speicher‑Cache nicht dauerhaft bleibt und bei Multi‑Prozess‑Umgebungen unsicher ist

---

## Wann sinnvoll einsetzbar? {#sec-181131104337}

- Lokale Entwicklungsumgebung  
- Ein‑Prozess‑Umgebung (oder „Cache‑Freigabe nicht nötig“)  
- Funktions‑Verifikation/Tests (minimale externe Abhängigkeiten)

Im Gegensatz dazu, wenn **mehrere Prozesse/Server denselben Cache gemeinsam nutzen** müssen, ist ein geteilter Cache wie Redis oder Memcached die bessere Wahl.