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

![로봇들의 데이터 보관소 이미지](/media/editor_temp/6/62743df3-4837-47d2-b16a-a458240f5629.png)

`LocMemCache` ist der **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**

* **Speicherort:** RAM des aktuell laufenden **Django-Prozesses**
* **Freigabeumfang:** **Nicht über Prozesse hinweg geteilt (per-process)**
* **Eigenschaft:** **thread‑sicher**

---

## Welche Probleme löst es? {#sec-d5ce9d49504b}

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:

* Erste Anfrage: DB‑Abfrage → Ergebnis im Cache speichern
* 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-5812aa71ede8}

### 1) „Prozess‑basiert“ (am wichtigsten) {#sec-82e1553d2867}

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-b592565e73f5}

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

### 3) Beim Neustart verschwindet der Cache {#sec-56535f9324da}

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

---

## Konfiguration {#sec-ed6e3fa738df}

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-38c232e71484}

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

* **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-99e7489ed70c}

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