Was ist Django LocMemCache (lokaler Speicher-Cache)?

Roboter-Datenlager

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

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

Welche Probleme löst das?

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

Commandbox 광고

1) Prozess‑basiert (am wichtigsten)

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

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

3) Beim Neustart verschwindet der Cache

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

Konfiguration

In settings.py wird CACHES mit dem BACKEND definiert.

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

  • 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

  • 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?

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