django

Cachowanie w Django – warstwy, metody i najlepsze praktyki

Puszcza Py

12 sty 2025 • 42 min read

Cachowanie (ang. caching) jest kluczową techniką optymalizacji wydajności aplikacji webowych. Django oferuje wiele możliwości cachowania na różnych poziomach – od przeglądarki użytkownika, przez serwer pośredniczący (reverse proxy) jak Varnish, po wewnętrzny cache framework Django i zewnętrzne magazyny pamięci (Redis/Memcached). W tym obszernym wpisie omawiamy warstwy cache w Django, kiedy stosować konkretne metody, prezentujemy przykłady kodu implementacji oraz najlepsze praktyki unikania nieświeżych danych i unieważniania cache. Na koniec przyglądamy się bibliotece Django-Cachalot (Cachelot) do automatycznego cachowania zapytań ORM – wyjaśniamy, co to jest, jakie daje korzyści i kiedy warto ją użyć.

(Uwaga: W celu uwiarygodnienia informacji zamieszczono odniesienia do źródeł w formacie【x†Ly-Lz】.)

Warstwy cache w aplikacjach Django

Skuteczne cachowanie zwykle odbywa się w wielu warstwach jednocześnie. Każda warstwa przechowuje dane na innym etapie przetwarzania żądania, co zwiększa szanse na uniknięcie kosztownych operacji. Poniżej opisujemy najważniejsze warstwy cache w typowej aplikacji Django:

Cache przeglądarki (po stronie klienta)

Cache na poziomie przeglądarki wykorzystuje mechanizmy HTTP do przechowywania zasobów (stron HTML, plików CSS/JS, obrazów) w pamięci przeglądarki użytkownika. Dzięki temu przy ponownym wczytaniu strony przeglądarka może użyć lokalnej kopii zasobu zamiast pobierać go z serwera, co znacząco przyspiesza czas ładowania. Sterowanie cache przeglądarki odbywa się za pomocą nagłówków HTTP, takich jak Cache-Control (HTTP/1.1) i Expires (HTTP/1.0) (Django HTTP headers: Controlling caching on cn.ubuntu.com). Na przykład nagłówek Cache-Control: max-age=300 informuje, że dany zasób może być przechowywany przez 5 minut, natomiast Expires ustala konkretną datę/godzinę wygaśnięcia (Django HTTP headers: Controlling caching on cn.ubuntu.com).

W Django możemy ustawiać te nagłówki ręcznie lub skorzystać z wbudowanych narzędzi. Dekorator django.views.decorators.cache.cache_control pozwala np. oznaczyć widok odpowiednimi dyrektywami cache, a funkcja pomocnicza patch_response_headers(response, cache_timeout=sekundy) automatycznie doda nagłówki Cache-Control i Expires do obiektu HttpResponse (Django HTTP headers: Controlling caching on cn.ubuntu.com) (Django HTTP headers: Controlling caching on cn.ubuntu.com). W praktyce częstą strategią jest bardzo długie cachowanie zasobów statycznych (np. plików CSS/JS) – nawet przez rok – z jednoczesnym stosowaniem cache busting, czyli zmiany URL (np. poprzez dodanie hasza pliku) przy każdej aktualizacji pliku (Django HTTP headers: Controlling caching on cn.ubuntu.com). Dzięki temu użytkownik nigdy nie zobaczy nieaktualnej wersji pliku, a jednocześnie przeglądarka może agresywnie cache’ować niezmienione zasoby.

Cache przeglądarki świetnie się sprawdza dla zasobów statycznych i treści rzadko zmieniających się. Należy jednak ostrożnie cache’ować pełne strony HTML po stronie klienta – jeśli już, to na bardzo krótki okres – aby użytkownik nie pozostał z nieświeżą zawartością (np. starymi danymi lub przeterminowanym koszykiem w sklepie). Podsumowując: wykorzystujmy nagłówki HTTP, by podpowiadać przeglądarce, co i na jak długo może cache’ować. To odciąża serwer i przyspiesza odbiór stron przez użytkownika (Django’s cache framework | Django documentation | Django).

Reverse proxy cache (Varnish i inne)

Reverse proxy cache to warstwa pośrednia między klientem a aplikacją Django – może to być dedykowany serwer HTTP cache (np. Varnish, Squid) lub usługa CDN. Reverse proxy odbiera żądania HTTP od użytkowników i próbuje obsłużyć je z własnego cache, zanim przekaże je do Django. Taki upstream cache jest niezwykle wydajny, potrafi serwować strony bez uruchamiania procesu aplikacji, co odciąża serwer aplikacyjny (Django Caching Strategies). Przykładowo, Varnish potrafi przechowywać wygenerowane strony w pamięci RAM i obsługiwać tysiące zapytań na sekundę, zanim jakiekolwiek trafi do aplikacji.

Reverse proxy idealnie nadaje się do cache’owania całych stron lub ich dużych fragmentów, zwłaszcza dla niezalogowanych użytkowników (treści publiczne). W konfiguracji Varnish możemy definiować, które URL-e i na jak długo cache’ować, kiedy je unieważniać, a także omijać cache dla pewnych żądań (np. gdy użytkownik ma zalogowaną sesję – poprzez analizę cookie). Upstream cache może nawet przechowywać wiele wariantów strony w zależności od warunków (np. inna wersja dla różnych języków czy urządzeń) (Django Caching Strategies).

Typowy scenariusz: jeśli większość ruchu na stronie stanowią anonimowi użytkownicy, reverse proxy cache może obsłużyć znaczną część żądań samodzielnie. Przykład: Reddit w swoim blogu opisuje użycie Varnisha jako bufora przed aplikacją webową, który drastycznie zmniejsza obciążenie backendu (Django Caching Strategies). Warstwa ta jest bardzo efektywna dla stron o wysokim ruchu, zapewnia niskie czasy odpowiedzi i redukuje koszty infrastruktury (mniej obciążonych procesów aplikacji) (Django Caching Strategies) (Django Caching Strategies).

Warto pamiętać, że cache na poziomie proxy respektuje nagłówki cache generowane przez aplikację. Jeśli Django ustawi Cache-Control: max-age=600 i brak nagłówka Vary wskazującego na zależność od ciasteczek czy parametrów, Varnish może spokojnie zcache’ować taką stronę na 10 minut. Dobrą praktyką jest więc staranne zarządzanie nagłówkami HTTP (Expires, Cache-Control, Vary) w aplikacji, aby sterować zarówno cache przeglądarki, jak i proxy.

Podsumowując, reverse proxy (np. Varnish) to doskonała metoda cache’owania całych stron dla dużego ruchu i treści publicznych. Stosuj ją, gdy chcesz odciążyć Django od generowania powtarzalnych stron i przyspieszyć czas odpowiedzi globalnie. Pamiętaj jednak o konfiguracji wyjątków dla treści dynamicznych (np. spersonalizowanych), aby nie serwować użytkownikom cudzych danych.

Cache po stronie aplikacji Django (cache framework)

Django posiada własny framework cache do cache’owania po stronie serwera aplikacji. Działa on wewnątrz procesu Django i pozwala cache’ować różne elementy: całe strony (site-wide cache), wyniki poszczególnych widoków (per-view cache), fragmenty szablonów (template fragment cache), a także dowolne dane w kodzie (manualny cache). Dane te przechowywane są w wybranym backendzie cache (o czym dalej) – np. w pamięci, pliku, bazie danych lub serwerze typu Memcached/Redis.

Cache w Django jest często określany jako downstream cache – działa po stronie aplikacji, już po otrzymaniu żądania, ale zanim nastąpi kosztowna logika lub zapytania do bazy (Django Caching Strategies). Choć nie jest tak szybki jak cache w proxy (bo wymaga uruchomienia obsługi żądania w Django), ma inne zalety: jest zintegrowany z kodem aplikacji, więc może podejmować bardziej zaawansowane decyzje (np. cache’ować tylko dla określonych użytkowników lub parametrów) (Django Caching Strategies).

Framework cache Django oferuje kilka strategii:

Cache całej witryny (site-wide): Włącza się go poprzez middleware. Dodanie 'django.middleware.cache.UpdateCacheMiddleware' jako pierwszego i 'django.middleware.cache.FetchFromCacheMiddleware' jako ostatniego middleware automatycznie powoduje cache’owanie wszystkich odpowiedzi HTTP (spełniających kryteria) na określony czas (Django’s cache framework | Django documentation | Django) (Django’s cache framework | Django documentation | Django). W ustawieniach definiujemy CACHE_MIDDLEWARE_SECONDS (czas cache dla każdej strony) i ewentualnie CACHE_MIDDLEWARE_KEY_PREFIX (prefiks klucza, przydatny gdy wiele stron dzieli jeden cache) (Django’s cache framework | Django documentation | Django). Ten mechanizm zapisuje w cache każdą stronę wygenerowaną przez Django (zwykle dla metod GET i HEAD) i przy kolejnym żądaniu do tego samego URL zwraca ją z pamięci zamiast generować od nowa (Django’s cache framework | Django documentation | Django). Middleware automatycznie ustawia też nagłówki Expires i Cache-Control na podstawie czasu trwania cache (Django’s cache framework | Django documentation | Django), co wpływa na cache przeglądarki i proxy. Rozwiązanie to jest proste w użyciu, ale mniej elastyczne – cache’uje globalnie wszystko lub nic. Sprawdza się np. w aplikacjach informacyjnych, gdzie cała strona może być keszowana dla wszystkich użytkowników.
Cache fragmentu szablonu: Django umożliwia cache’owanie części strony (fragmentu HTML) poprzez znacznik szablonu {% cache %}. Używamy go w template, obejmując blok HTML, i podajemy klucz oraz czas cache. Np. {% cache 300 sidebar user.id %} może na 5 minut zcache’ować kod generujący panel boczny dla danego użytkownika (klucz zawiera user.id, więc każdy użytkownik ma osobny fragment) (Django Caching Strategies). Fragment cache jest świetny, gdy strona jako całość nie nadaje się do pełnego cache (np. zawiera elementy spersonalizowane), ale ma fragmenty wspólne, kosztowne do wygenerowania (np. skomplikowane menu, sekcja często zadawanych pytań, widget pogody itp.). Dzięki temu możemy mieszać treść dynamiczną z fragmentami statycznymi – dynamiczna część jest generowana normalnie, a ciężkie fragmenty wstawiane z cache.

Ręczne użycie cache (low-level API): W kodzie Python możemy bezpośrednio korzystać z API cache Django, aby zapisywać i odczytywać dowolne dane. Importujemy obiekt cache: from django.core.cache import cache i używamy metod takich jak cache.set(klucz, wartość, timeout) oraz cache.get(klucz) (Enhancing Performance and Efficiency in Django Applications through Caching | MoldStud). To daje pełną kontrolę – możemy keszować wyniki kosztownych operacji (np. wynik zapytania do zewnętrznego API, złożone obliczenia) i samodzielnie decydować, kiedy je odświeżyć. Przykład:

from django.core.cache import cache

def moja_widok(request):
    dane = cache.get('wynik_zapytania')
    if not dane:
        dane = expensive_query()   # np. kosztowne zapytanie do bazy
        cache.set('wynik_zapytania', dane, 300)  # cache na 5 minut
    return render(request, "szablon.html", {"dane": dane})

Przy pierwszym żądaniu wykona się expensive_query() i wynik zostanie zapisany pod kluczem 'wynik_zapytania'. Kolejne odczytają gotowy wynik z pamięci, pomijając drogą operację. Samodzielne zarządzanie cache jest bardziej pracochłonne, ale niezbędne w sytuacjach, gdy automatyczne mechanizmy (per-site, per-view, fragmenty) nie pasują do danego przypadku użycia. Pamiętajmy, aby klucze cache były unikalne i zawierały wszelkie zmienne, od których zależy dana wartość (np. ID użytkownika, wersję danych itd.), żeby uniknąć kolizji lub – co gorsza – pokazania komuś nie jego danych.

Cache widoku (per-view): Bardziej granularne podejście, cache’ujące wynik konkretnej funkcji widoku. Django udostępnia dekorator @cache_page(timeout) – wystarczy opatrzyć nim widok, by jego wynik został automatycznie zapisany w cache na podany czas (timeout w sekundach) (Django’s cache framework | Django documentation | Django). Przykład:

from django.views.decorators.cache import cache_page

@cache_page(60 * 15)  # cache na 15 minut
def lista_artykulow(request):
    # ... generate response ...
    return response

Pierwsze wywołanie lista_artykulow wygeneruje odpowiedź normalnie i zapisze ją w cache pod kluczem związanym z URL (np. /artykuly/), a kolejne wywołania w ciągu 15 minut zwrócą tę samą zawartość z pominięciem logiki widoku (Django’s cache framework | Django documentation | Django) (Django’s cache framework | Django documentation | Django). Dekorator ten domyślnie używa cache 'default', ale można wskazać inny alias (@cache_page(60, cache="my_cache")) oraz dodać prefiks klucza (key_prefix), jeśli chcemy odróżnić cache dla podobnych widoków (Django’s cache framework | Django documentation | Django) (Django’s cache framework | Django documentation | Django). Warto wiedzieć, że cache_page automatycznie ustawia również nagłówki HTTP Cache-Control/Expires w odpowiedzi, dzięki czemu przeglądarki i proxy także mogą cache’ować tę odpowiedź (Django’s cache framework | Django documentation | Django). Cache per-view jest wygodny, gdy pojedynczy widok jest bardzo „ciężki”, a jednocześnie jego wynik jest taki sam dla wielu użytkowników (lub różni się tylko parametrami ujętymi w URL). Należy pamiętać o parametrach zapytania – domyślnie różne querystringi traktowane są jako osobne wersje strony i cache’owane osobno.

Podsumowując: cache po stronie Django pozwala cache’ować treści na różnych poziomach szczegółowości. Per-site i per-view cache są łatwe w użyciu i potrafią drastycznie zmniejszyć liczbę zapytań do bazy oraz czas renderowania przy powtarzalnych żądaniach (Django’s cache framework | Django documentation | Django). Fragmenty i cache ręczny dają elastyczność, pozwalając keszować to, co najdroższe w generowaniu strony. Wybór zależy od charakteru aplikacji – czasem użyjemy kombinacji tych technik jednocześnie dla optymalnego efektu (np. cache całej strony dla niezalogowanych + fragmenty cache dla zalogowanych itp.).

Cache w Django ORM (cache zapytań do bazy)

Oprócz cache’owania całych widoków czy fragmentów, można cache’ować wyniki zapytań do bazy danych wykonywanych przez Django ORM. Standardowo, jeśli w dwóch różnych żądaniach wywołamy np. Article.objects.filter(published=True) – każde spowoduje zapytanie SQL do bazy. Idea cache ORM polega na tym, by wynik pierwszego zapytania zachować w pamięci i przy kolejnym, identycznym zapytaniu zwrócić rezultat z cache zamiast ponownie pytać bazę. Takie podejście odciąża bazę danych przy powtarzalnych odczytach i może znacząco przyspieszyć aplikację przy dużym ruchu.

Django nie posiada wbudowanego mechanizmu pełnego cache ORM, ale istnieją popularne biblioteki rozszerzające ORM o tę funkcję. Należą do nich m.in. Johnny Cache, django-cache-machine, django-cacheops oraz django-cachalot (nazywany potocznie Cachelot). Wszystkie one działają na podobnej zasadzie: przechwytują wykonywanie zapytań ORM, sprawdzają cache i zapisują wyniki, a także unieważniają cache przy zmianie danych.

Johnny Cache – jedna z pierwszych bibliotek tego typu, obecnie rzadziej używana.
django-cache-machine – wprowadza warstwę CachingQuerySet, która cache’uje wyniki querysetów i usuwa je z cache przy zapisie/aktualizacji obiektów (m.in. poprzez utrzymywanie tzw. flush lists powiązanych z obiektami, by wiedzieć które cache unieważnić przy zmianach) (python - Why is Django returning stale cache data? - Stack Overflow) (python - Why is Django returning stale cache data? - Stack Overflow).
django-cacheops – nowsza biblioteka wykorzystująca Redis, umożliwiająca m.in. cache na poziomie pojedynczych obiektów i zapytań z użyciem dekoratorów przy definicji modeli.
django-cachalot (Cachelot) – biblioteka, na której skupimy się szerzej (patrz sekcja Django-Cachalot poniżej). W skrócie, jest to automatyczny cache zapytań ORM dla Django – instaluje się go jako aplikację i działa transparentnie. Cachalot zapisuje w cache wyniki wszystkich zapytań SELECT wykonywanych przez ORM i przy ponownym wykonaniu tego samego zapytania zwraca rezultat z cache, zamiast pytać bazę (Debian -- Details of package python-django-cachalot-doc in sid). Co ważne, śledzi on zmiany w bazie (INSERT/UPDATE/DELETE) i automatycznie unieważnia powiązane wyniki w cache, aby zachować spójność danych (Debian -- Details of package python-django-cachalot-doc in sid). Inaczej mówiąc, cachalot dba o to, by cache się nie zestarzał – jeśli dane w tabeli się zmieniły, wszystkie cache zapytań dotyczących tej tabeli zostaną usunięte. W praktyce unieważnia całe tabelowe cache – każda modyfikacja obiektu usuwa z cache wszystkie zapytania dotyczące tej tabeli (oraz powiązanych przez klucze obce) (Introduction — django-cachalot 2.6.3 documentation). Jest to prostsze i bardziej niezawodne niż próba unieważniania tylko konkretnego obiektu (co bywa zawodne), kosztem tego, że częste zmiany będą czyścić sporo cache.

Cache na poziomie ORM jest szczególnie przydatny w aplikacjach, gdzie często wykonujemy powtarzalne zapytania do bazy – np. czytamy te same listy rekordów, statystyki, konfiguracje – i gdzie odczytów jest dużo więcej niż zapisów. W takich scenariuszach można osiągnąć ogromny spadek obciążenia bazy danych, bo każde powtórne zapytanie jest obsłużone z pamięci. Według dokumentacji, django-cachalot sprawia, że przy dużej liczbie odwiedzin strona tym bardziej przyspiesza – im więcej zapytań zostało wcześniej wykonanych, tym więcej wyników siedzi w cache (Introduction — django-cachalot 2.6.3 documentation). W typowych przypadkach pierwsze zapytanie jest ~10% wolniejsze (narzut na zapis do cache), ale kolejne są średnio 7x szybsze (Introduction — django-cachalot 2.6.3 documentation).

Trzeba jednak podkreślić, że cache ORM nie jest panaceum dla każdej aplikacji. Jeżeli nasza aplikacja ma bardzo dużo zapisów (ciągle zmieniające się dane), to taki cache może być mniej skuteczny lub nawet obniżyć wydajność z powodu ciągłego unieważniania. Autor django-cachalot zaznacza, że nie jest on zalecany np. dla serwisów społecznościowych, gdzie na tabelę może przypadać >50 modyfikacji na minutę – w takim przypadku cachalot będzie co chwilę czyścił cały cache tabeli i niewiele z niego pożytku (Introduction — django-cachalot 2.6.3 documentation) (django-cachalot — django-cachalot 2.6.3 documentation). W skrajnym razie przy bardzo częstych zmianach cache ORM może nawet nieco spowalniać (narzut i tak nic nie cache’uje), więc lepiej skupić się na optymalizacji samej bazy/zapytań (Introduction — django-cachalot 2.6.3 documentation). Z kolei w projektach o dominujących odczytach (treści, które rzadko się zmieniają) cache ORM jest świetnym narzędziem – bezpiecznie przyspieszy aplikację bez potrzeby ręcznego dodawania cache w kodzie.

Backendy cache: Memcached i Redis

Niezależnie od warstwy cache, wszystkie wyżej opisane mechanizmy potrzebują magazynu, gdzie będą przechowywać dane cache. Tym magazynem jest cache backend konfigurowany w Django. Dwa najpopularniejsze rozwiązania to Memcached i Redis, które działają w pamięci RAM i oferują błyskawiczny odczyt/zapis danych.

Memcached – to wyspecjalizowany, rozkładowy cache w pamięci, używany od lat w wielu dużych serwisach (jak Facebook, Wikipedia) do odciążania baz danych (Django’s cache framework | Django documentation | Django). Memcached działa jako osobny serwer (daemon) w tle – aplikacja łączy się z nim przez sieć (TCP lub unix socket) i przechowuje proste pary klucz-wartość. Jest bardzo szybki i prosty – dane są trzymane w RAM, brak skomplikowanych struktur (tylko tablica haszująca). Obsługuje rozproszenie danych na wiele instancji (klient biblioteki decyduje, na którym serwerze umieścić dany klucz). Django ma wbudowaną obsługę memcache – dostępne backendy to m.in. django.core.cache.backends.memcached.MemcachedCache lub nowsze PyMemcacheCache/PyLibMCCache (różnice dotyczą użytej biblioteki Python). Konfiguracja jest prosta, np. w settings.py:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",
        "LOCATION": "127.0.0.1:11211",
    }
}

powyższe ustawia cache domyślny na memcached nasłuchujący na porcie 11211 lokalnie (Django’s cache framework | Django documentation | Django). Można podać listę serwerów (dla klastrowania) lub ścieżkę socketu. Memcached jest świetny do prostego cache na dużą skalę – cechuje go przewidywalnie niskie opóźnienie i mały narzut, właśnie dzięki prostocie struktur (caching - Memcached vs. Redis? - Stack Overflow). Warto jednak pamiętać, że memcached nie zapewnia trwałości danych – po restarcie procesu cache jest pusty (co zwykle nie jest problemem, bo cache można przebudować). Ponadto memcached nie przechowa obiektów większych niż ok. 1MB (limit rozmiaru elementu) i nie posiada zaawansowanych typów danych (tylko bajty/ciągi znaków). Mimo to, do typowego cachowania stron, fragmentów czy wyników zapytań nadaje się doskonale. Jest także bardzo skalowalny poziomo – możemy dodać więcej serwerów memcache i klient automatycznie zacznie rozkładać klucze między nie (np. konsystentne haszowanie).

Redis – to in-memory data store, który może pełnić rolę cache podobnie jak memcached, ale oferuje dużo więcej możliwości. Redis przechowuje dane w pamięci, lecz opcjonalnie może je persistować na dysku (snapshoty lub log zmian), dzięki czemu po restarcie możemy odzyskać stan (choć cache zwykle tego nie wymaga). Jego główną zaletą jest obsługa różnorodnych struktur danych (lista, hash, posortowany zestaw itp.) i dodatkowych operacji (np. inkrementacje, pub/sub). W kontekście Django zwykle używamy Redisa do cache tak samo jak memcache (klucz-wartość), ale możemy też wykorzystać jego funkcje do bardziej zaawansowanych scenariuszy. Django od wersji 4.0+ ma wbudowany backend django.core.cache.backends.redis.RedisCache (Django’s cache framework | Django documentation | Django), a we wcześniejszych łatwo integruje się poprzez bibliotekę django-redis. Przykładowa konfiguracja Redis jako cache:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/1",
    }
}

W powyższym przykładzie korzystamy z bazy Redis nr 1 na lokalnym serwerze (Django’s cache framework | Django documentation | Django). Redis jest często polecany jako nowocześniejsze rozwiązanie niż memcached – jest bardzo szybki (podobnie sub-milisekundowe czasy dostępu) i znacznie bardziej funkcjonalny (caching - Memcached vs. Redis? - Stack Overflow). Dzięki persystencji może być użyty także do przechowywania sesji, kolejek zadań czy innych danych, co czyni go uniwersalnym elementem architektury. W kontekście czystego cache, Redis pozwala np. ustawiać globalny TTL dla wszystkich kluczy z prefiksem, usuwać klucze według wzorca, używać trybu LRU/LFU (wyrzucanie najrzadziej używanych) itp. Memcached z kolei bywa minimalnie prostszy i lżejszy – ma nieco bardziej przewidywalne zużycie pamięci i nieco mniej narzutu, dzięki czemu w pewnych testach na bardzo prostych operacjach może być ciut szybszy, choć różnice są niewielkie (caching - Memcached vs. Redis? - Stack Overflow) (caching - Memcached vs. Redis? - Stack Overflow). Oba rozwiązania doskonale nadają się do Django – wybór często zależy od preferencji, istniejącej infrastruktury lub potrzeb spoza samego cache (jeśli potrzebujemy dodatkowych możliwości – wybierzemy Redis).

Korzystanie z zewnętrznego cache (Memcached/Redis) jest w zasadzie koniecznością przy większych projektach Django. Alternatywne backendy jak LocMemCache (cache w pamięci procesu) czy FileBasedCache sprawdzają się tylko lokalnie lub przy małej skali, bo np. cache w pamięci procesu nie jest współdzielony między procesami/workerami (więc każdy serwer ma inny cache, co utrudnia spójność), a plikowy jest stosunkowo wolny. Memcached i Redis działają jak usługa współdzielona – wszystkie instancje aplikacji odczytują i zapisują do jednego miejsca, dzięki czemu każdy widzi ten sam stan cache. To ważne dla spójności w środowisku rozproszonym (klaster aplikacji). Dodatkowo są przystosowane do dużej liczby operacji na sekundę i optymalizowane pod kątem właśnie cache.

Krótkie porównanie: jeśli potrzebujesz tylko prostego, szybkiego cache do akceleracji strony – memcached w zupełności wystarczy (jest prosty w utrzymaniu). Jeśli chcesz dodatkowych możliwości lub ujednolicenia infrastruktury (np. używasz Redisa też do innych celów), Redis będzie świetnym wyborem. Wiele aplikacji zaczyna od memcached, a z czasem przechodzi na Redis dla większej elastyczności. Oba systemy osiągają podobne czasy dostępu rzędu mikro- lub milisekund (caching - Memcached vs. Redis? - Stack Overflow), więc z punktu widzenia szybkości cache dla Django – oba są bardzo dobre. Warto natomiast unikać trzymania cache w bazie danych Django (DatabaseCache), bo to niweluje większość korzyści (cache znów obciąża bazę) oraz w plikach (chyba że naprawdę nie ma innej opcji).

Kiedy stosować poszczególne metody cachowania?

Mając przegląd dostępnych warstw i technik cache, zastanówmy się kiedy która metoda jest najbardziej odpowiednia. Oto kilka wskazówek i typowych scenariuszy:

Cache przeglądarki: Stosuj do zasobów statycznych (obrazy, skrypty, style) i elementów, które mogą bezpiecznie być wspólne dla wielu użytkowników i nie zmieniają się przy każdym odświeżeniu. Ustaw długie czasy cache (dni, tygodnie, nawet rok) dla plików, którym zmieniasz nazwę po aktualizacji (tzw. cache busting – np. plik app.abc123.js po zmianie staje się app.def456.js). Dla dynamicznych treści HTML możesz ustawić krótki max-age (kilka minut) jeśli akceptujesz ewentualną chwilową nieaktualność w zamian za odciążenie serwera. Pamiętaj, że cache przeglądarki nie odciąża Twojego serwera aplikacji przy pierwszym żądaniu – działa dopiero przy kolejnych odświeżeniach przez tego samego użytkownika. To bardziej optymalizacja doświadczenia użytkownika (UX) i ruchu sieciowego, niż skalowania serwera.
Cache w reverse proxy (Varnish/CDN): Używaj, gdy masz wysoki ruch i wiele powtarzalnych żądań tej samej treści (zwłaszcza od anonimowych użytkowników). Reverse proxy doskonale się sprawdzi przy stronach informacyjnych, portalach, blogach – gdzie np. strona artykułu jest jednakowa dla wszystkich odwiedzających. Takie strony można keszować na poziomie Varnish nawet przez kilkanaście minut czy godzin, zależnie od tego jak często się zmieniają. W efekcie większość hitów obsłuży Varnish z pamięci, a Django zostanie wywołane tylko sporadycznie (przy miss). Reverse proxy jest też świetne, gdy wolno generuje się strona – np. złożone obliczenia – i nie chcesz, by każdy użytkownik musiał czekać. Wystarczy, że pierwszy wykona ciężką operację, a reszta dostanie gotowy wynik z cache. Nie stosuj pełnego cache proxy dla treści ściśle spersonalizowanych (np. panel użytkownika po zalogowaniu) – albo je w ogóle pomijaj, albo korzystaj z mechanizmów typu ESI (Edge Side Includes) lub wariantów cache per użytkownik (np. Vary: Cookie – choć to ogranicza skuteczność) (Django Caching Strategies). Podsumowując: reverse proxy jest pierwszą linią obrony przy dużym ruchu – odciąża aplikację i skraca czas odpowiedzi globalnie.
Cache po stronie Django (site-wide, per-view): Stosuj, gdy nie masz możliwości wprowadzenia cache na poziomie proxy (np. w środowisku PaaS gdzie nie kontrolujesz takiego elementu) lub jako uzupełnienie. Per-site cache (middleware) jest najprostszy – włączasz i zapominasz – dobry, gdy większość Twoich stron może być keszowana w ten sam sposób. Np. aplikacja, w której prawie każda strona może być odświeżana co 5 minut, bo dane nie zmieniają się szybciej (lub nie są krytycznie aktualne). Jeśli jednak część widoków musi być świeża zawsze, a inne można keszować, lepiej użyć per-view cache selektywnie tylko tam, gdzie ma to sens. Na przykład: kosztowny widok generujący raporty – warto go keszować na 10 minut, bo niech się odświeża rzadziej; prosta strona kontaktowa – nie ma potrzeby cache. Per-view cache stosuj też, gdy różne widoki wymagają różnych czasów przechowywania. Pamiętaj, że cache_page bazuje na URL – jeśli ten sam widok jest pod różnymi URL, każdy będzie keszowany osobno (Django’s cache framework | Django documentation | Django).
Cache fragmentów szablonów: Wykorzystaj, gdy tylko fragment strony jest kosztowny w generowaniu, a całość strony nie nadaje się do globalnego cache. Przykładem może być witryna e-commerce: strona produktu zawiera dane produktu (zmieniają się rzadko) oraz sekcję "produkty rekomendowane dla Ciebie" (spersonalizowane, zmienne). Możemy keszować fragment z danymi produktu (np. opis, zdjęcia) na dłużej, a sekcję rekomendacji generować na bieżąco. Fragmenty są także pomocne przy komponentach wspólnych na wielu stronach – np. sidebar z najnowszymi wpisami bloga, stopka z listą tagów itp. Keszując je, zapewnimy że na każdej podstronie nie będzie potrzeby ponownie pobierać tych samych danych z bazy. Technika ta jest elastyczna i działa dobrze w połączeniu z innymi – np. strona może być częściowo keszowana w Varnish, a wewnątrz Django pewne fragmenty i tak odświeżane dynamicznie dla użytkownika.
Ręczny cache w kodzie (cache API): Używaj, gdy musisz keszować coś nietypowego, co nie jest czysto związane z widokiem czy szablonem. Na przykład wynik wywołania kosztownego API zewnętrznego: możesz go zapisać w cache na pewien czas, aby kolejne wywołania (nawet w różnych widokach) korzystały z gotowych danych. Innym przykładem jest cache’owanie części kontekstu szablonu – np. liczba online userów, którą dodajesz do każdej odpowiedzi – zamiast liczyć za każdym razem, policz raz na 30 sekund i trzymaj w cache. Manualny cache jest też przydatny, gdy budujesz własne mechanizmy cache invalidation – np. po zapisie obiektu chcesz skasować kilka powiązanych kluczy (do czego zaraz przejdziemy). Generalnie, gdy cokolwiek jest droższe w wytworzeniu niż w pobraniu z pamięci – rozważ cache. Jeśli odwrotnie (dane łatwo policzyć, rzadko używane) – szkoda wysiłku.
Cache zapytań (ORM cache): Włączenie cache na poziomie ORM (np. poprzez django-cachalot) ma sens, gdy Twoja aplikacja wykonuje wiele powtarzalnych zapytań do bazy, a zwłaszcza gdy pewne strony wykonują dużą liczbę podobnych odczytów. Przykład: strona główna portalu ładuje 10 różnych modułów, każdy pobiera coś z bazy (nowości, najnowsze komentarze, statystyki itp.). Bez cache ORM, przy każdym wejściu wszystkie moduły wykonają zapytania. Z cache ORM – tylko pierwsze wejście to zrobi, a kolejne w krótkim czasie odczytają dane z pamięci. To potrafi przyspieszyć stronę proporcjonalnie do liczby zapytań mniej wykonywanych. Cache ORM to także najmniej inwazyjna metoda – nie musisz w każdym miejscu owijać kodu cache.get/set, biblioteka robi to automatycznie. Stosuj więc, gdy masz aplikację czytającą dużo danych, z umiarkowaną liczbą modyfikacji danych. Unikaj natomiast, gdy Twoja baza jest ciągle zapisywana (systemy real-time, czaty, liczniki na żywo) – bo overhead cache ORM może nie nadążyć i będzie czyścił cache tak często, że niewiele zostanie do odczytu, a tylko spowolni zapisy (Introduction — django-cachalot 2.6.3 documentation). Wówczas lepiej samemu decydować, co ewentualnie cache’ować ręcznie, albo skupić się na optymalizacji baz danych.

Na koniec, warto wspomnieć, że łączenie wielu warstw cache jest często najskuteczniejsze. Nie musimy wybierać jednej metody – w praktyce dobrze zaprojektowany system używa wielu poziomów cachowania jednocześnie, co zwiększa odporność na obciążenie i uniki cache-miss na różnych etapach (Django Caching Strategies). Przykładowo: przeglądarka może cache’ować statyczne zasoby, CDN/Varnish całe strony dla niezalogowanych, wewnątrz Django fragmenty strony lub obiekty, a dodatkowo django-cachalot odciąża bazę. W najgorszym wypadku, gdy któraś warstwa nie trafi (miss), jest duża szansa, że inna warstwa już zapewniła cache hit (Django Caching Strategies). Taka wielowarstwowość zwiększa też niezawodność – awaria jednej warstwy (np. padnie serwer memcached) nie musi oznaczać katastrofy wydajności, bo inne warstwy nadal działają (Django Caching Strategies).

Oczywiście nie każda aplikacja potrzebuje pełnego zestawu – ale warto myśleć o cache holistycznie, projektując system z myślą o różnych poziomach.

Przykłady implementacji cachowania w Django

Przejdźmy teraz do konkretnych przykładów, jak zaimplementować omówione metody cachowania w praktyce. Pokażemy fragmenty kodu i konfiguracji dla najpopularniejszych technik: konfiguracja backendu cache (Memcached/Redis), użycie dekoratora @cache_page do cache widoku, ręczne użycie cache.get()/set(), włączenie middleware cache oraz zastosowanie biblioteki django-cachalot do cache ORM.

Konfiguracja backendu cache (Memcached lub Redis)

Aby korzystać z cache w Django, najpierw należy skonfigurować backend cache w ustawieniach. Django używa domyślnie aliasu 'default' dla cache – możemy skonfigurować wiele cache, ale skupmy się na domyślnym. W pliku settings.py dodaj wpis CACHES. Przykład dla Memcached:

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",
        "LOCATION": "127.0.0.1:11211",
    }
}

Powyżej ustawiliśmy backend Memcached korzystający z biblioteki pymemcache, łączący się na lokalnym hoście i porcie 11211 (Django’s cache framework | Django documentation | Django). Jeśli mamy Memcached na innym serwerze lub wiele instancji, LOCATION może być listą, np. ["mem1.example.com:11211", "mem2.example.com:11211"].

Analogicznie konfiguracja dla Redisa (Django 4+):

CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379/1",
    }
}

Ten przykład ustawia jako backend Redisa pod adresem 127.0.0.1:6379, używając bazy danych indeks 1 (Django’s cache framework | Django documentation | Django). W przypadku starszych wersji Django, można zamiast tego użyć backendu z biblioteki django-redis, np. 'BACKEND': "django_redis.cache.RedisCache" i dodatkowo 'OPTIONS': {'CLIENT_CLASS': "django_redis.client.DefaultClient"} (Django Caching 101: Understanding the Basics and Beyond - DEV Community).

Po takiej konfiguracji, w dowolnym miejscu aplikacji możemy zaimportować django.core.cache import cache i będzie on działał w oparciu o nasz backend (np. memcached). Uwaga: W środowisku deweloperskim, jeśli nie skonfigurujemy CACHES, Django użyje domyślnie LocMemCache (cache w pamięci procesu) – co do testów jest OK, ale w produkcji zalecamy Memcached/Redis.

Cache całej strony – middleware

Aby włączyć site-wide caching za pomocą middleware, edytujemy listę MIDDLEWARE w settings. Musimy wstawić dwa middleware’y: UpdateCacheMiddleware na początku i FetchFromCacheMiddleware na końcu łańcucha (Django’s cache framework | Django documentation | Django):

MIDDLEWARE = [
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.middleware.common.CommonMiddleware',  # CommonMiddleware powinien być po UpdateCache
    # ... inne middleware, np. autoryzacja, sesje ...
    'django.middleware.cache.FetchFromCacheMiddleware',
]

Jak widać, update jest na samym początku, a fetch na końcu (to nie pomyłka – kolejność jest odwrotna przy przetwarzaniu odpowiedzi) (Django’s cache framework | Django documentation | Django). Dodatkowo należy ustawić parametry:

CACHE_MIDDLEWARE_SECONDS = 600        # czas cache jednej strony (sekundy, tu 10 min)
CACHE_MIDDLEWARE_KEY_PREFIX = ""      # prefiks klucza cache (np. żeby odróżnić środowiska)
# CACHE_MIDDLEWARE_ALIAS = "default"  # alias cache, default jeśli nie zmieniamy

Po takiej konfiguracji, Django będzie automatycznie cache’ował wszystkie odpowiedzi HTTP 200 GET/HEAD na 600 sekund (Django’s cache framework | Django documentation | Django), o ile nagłówki nie zabraniają (np. jeśli widok ustawił Cache-Control: no-cache, to middleware odpuści). Klucze cache będą generowane na podstawie pełnego URL (łącznie z domeną i ewentualnie językiem/parametrami jeśli różne) oraz powyższego prefixu i aliasu. Middleware ten również doda nagłówki Expires i Cache-Control do każdej odpowiedzi ze status 200, dzięki czemu np. przeglądarka wie jak długo cache’ować tę stronę (Django’s cache framework | Django documentation | Django).

To podejście minimalnym kosztem daje globalny cache. Wyłączenie cache dla konkretnego widoku możemy osiągnąć dekoratorem @never_cache (ustawia nagłówek Cache-Control: no-store), co spowoduje, że UpdateCacheMiddleware pominie tę odpowiedź (Django’s cache framework | Django documentation | Django). Możemy też dynamicznie sterować czasem – np. ustawić w widoku krótszy max-age innym dekoratorem, a middleware uszanuje krótszy czas (Django’s cache framework | Django documentation | Django).

Cache pojedynczego widoku – dekorator `@cache_page`

Jeśli nie chcemy cache’ować wszystkiego, a tylko wybrane widoki, używamy dekoratora cache_page. Ten dekorator przyjmuje jeden argument obowiązkowy: timeout (czas życia cache w sekundach). Przykład użycia:

from django.views.decorators.cache import cache_page

@cache_page(60 * 15)  # cache na 15 minut
def popular_articles(request):
    articles = Article.objects.order_by('-views')[:10]
    return render(request, "popular.html", {"articles": articles})

Po zastosowaniu dekoratora, rezultat widoku popular_articles będzie automatycznie zapisywany w cache na 900 sekund (Django’s cache framework | Django documentation | Django). Oznacza to, że np. zapytanie GET do /popular/ wykona normalnie kod widoku tylko za pierwszym razem – zrenderuje template z artykułami i zapisze wynik (HTML) w pamięci. Kolejne uderzenia w ten sam URL w ciągu 15 minut odczytają gotowy HTML z cache i od razu zwrócą go klientowi, pomijając pobieranie z bazy i render szablonu.

Dekorator ten sprawdza się np. dla stron, które nie zmieniają się przy każdym wejściu, np. ranking popularnych treści, strona główna portalu informacyjnego, wyszukiwarka (jeśli ten sam query param daje ten sam wynik, choć tu trzeba uważać na parametry). Jeżeli widok przyjmuje parametry w URL (np. post/<id>), to każdy unikalny URL będzie miał osobny wpis cache – co jest logiczne (inny post to inna zawartość) (Django’s cache framework | Django documentation | Django). Dla parametru w querystring (?page=2 np.) również będą osobne wpisy cache.

Warto wspomnieć, że można ten dekorator stosować też nie bezpośrednio na widoku, ale w urls.py podczas definicji ścieżek – jeśli nie chcemy "brudzić" kodu widoku zależnością od cache. Wygląda to tak:

from django.views.decorators.cache import cache_page
from myapp.views import popular_articles

urlpatterns = [
    path("popular/", cache_page(900)(popular_articles)),
]

To równoważne z dekorowaniem w miejscu definicji funkcji (Django’s cache framework | Django documentation | Django) (Django’s cache framework | Django documentation | Django).

Analogicznie jak w przypadku middleware, możemy użyć dekoratora @cache_control aby np. ustawić public/private czy inne dyrektywy, albo @vary_on_cookie jeśli cache ma brać pod uwagę cookies (np. sesję). Django dba, by klucze cache per-view nie mieszały się przypadkowo – możemy ustawić globalny KEY_PREFIX w konfiguracji CACHES lub przekazać key_prefix do dekoratora jeśli potrzebujemy (np. w multi-site, by ten sam URL na różnych stronach miał różne wpisy) (Django’s cache framework | Django documentation | Django).

Ręczne użycie cache – `cache.get()` / `cache.set()`

Czasem musimy samodzielnie zarządzać cache w kodzie – np. keszować wynik drogiej operacji, który jest wykorzystywany wewnątrz widoku (nie jako końcowy HTML). Albo chcemy cache’ować dane używane przez wiele różnych miejsc. Django udostępnia do tego celu uniwersalny interfejs. Po skonfigurowaniu CACHES jak wyżej, używamy go np. tak:

from django.core.cache import cache

def stats_view(request):
    # Próbujemy pobrać wynik z cache
    stats = cache.get("homepage_stats")
    if stats is None:
        # Jeśli brak w cache, liczymy (np. kilka zapytań do bazy)
        stats = {
            "users": User.objects.count(),
            "posts": Post.objects.count(),
            "comments": Comment.objects.count(),
        }
        # zapisujemy do cache na 5 minut
        cache.set("homepage_stats", stats, 300)
    # używamy stats dalej, np. przekazujemy do szablonu
    return render(request, "stats.html", stats)

W powyższym przykładzie, przy pierwszym wejściu na stronę statystyk wykonają się trzy zapytania do bazy (liczenie użytkowników, postów, komentarzy). Następnie słownik z wynikami zostanie zapisany w cache pod kluczem "homepage_stats" na 300 sekund. Kolejne odwołania w tym czasie nie będą już liczyć w bazie, tylko odczytają gotowe dane z pamięci.

Ta metoda daje nam pełną kontrolę: sami decydujemy co i kiedy trafia do cache oraz kiedy zostaje odświeżone. Możemy też używać metod takich jak cache.has_key(), cache.delete(key), cache.clear() (usuwa cały cache danej konfiguracji) itp. To przydatne do manualnego inwalidowania cache, np. po zapisie ważnego obiektu możemy wykasować powiązane klucze (więcej o tym w najlepszych praktykach).

UWAGA: Przy ręcznym korzystaniu z cache należy uważać na klucze. Dobrą praktyką jest nadawanie kluczom przestrzeni nazw lub prefixów unikalnych dla danej funkcjonalności, np. "user_{id}_profile_data" itp. Wtedy łatwiej uniknąć kolizji (dwóch różnych miejsc używających tego samego klucza) i łatwiej unieważnić grupę kluczy (np. wszystkie klucze zaczynające się od "user_42_" gdy użytkownik 42 się zmienił). Jeśli budujemy bardziej rozbudowane mechanizmy czyszczenia cache, można w kluczach umieszczać np. wersje lub używać dodatkowej warstwy, ale to temat na osobny akapit.

Cache ORM – użycie django-cachalot (Cachelot)

Aby skorzystać z automatycznego cache zapytań ORM, musimy zainstalować odpowiednią bibliotekę. Załóżmy, że wybieramy django-cachalot. Instalujemy paczkę (np. pip install django-cachalot) i dodajemy ją do INSTALLED_APPS w settings:

INSTALLED_APPS = [
    # ... inne aplikacje ...
    'django_cachalot',
]

Domyślnie django-cachalot będzie używał domyślnego cache Django (CACHES['default']) do przechowywania wyników zapytań. Ważne więc, by ten cache był skonfigurowany na szybki backend (np. Redis/Memcached) – inaczej nie ma to sensu. Możemy dodatkowo ustawić opcjonalne parametry konfiguracyjne cachalot, np. CACHALOT_TIMEOUT (czas cache globalnie, domyślnie wieczny aż do invalidation) albo CACHALOT_ONLY_CACHABLE_TABLES/UNCACHABLE_TABLES by ograniczyć które modele cache’ować. Jednak w prostym użyciu nie trzeba nic poza dodaniem aplikacji.

Po tej konfiguracji, wszystkie zapytania ORM w naszej aplikacji są automatycznie keszowane. Gdy w widoku wykonamy Article.objects.filter(published=True), cachalot sprawdzi, czy wynik tego zapytania (zapytanie identyfikowane po odpowiadającym mu SQL) jest w cache. Jeśli nie – wykona je i zapisze rezultat (listę obiektów/ich danych) do cache. Przy kolejnym wykonaniu identycznego querysetu, wynik zostanie pobrany z cache zamiast z bazy (Debian -- Details of package python-django-cachalot-doc in sid). Dzieje się to całkowicie transparentnie – w kodzie nie ma żadnej różnicy, obiekty zwracane z cache zachowują się jak normalne instancje modelu.

Co z aktualnością danych? Gdy gdziekolwiek w Django nastąpi zapis/aktualizacja/usunięcie obiektu, django-cachalot to wychwyci (podpina się do wewnętrznych sygnałów lub korzysta ze swojej logiki) i unieważni wszystkie cache zapytań dotyczących zmodyfikowanej tabeli (Introduction — django-cachalot 2.6.3 documentation). Dzięki temu nie musimy się obawiać, że dostaniemy przestarzałe wyniki – jeśli dane się zmieniły, to następnym razem zapytanie po nie trafi do bazy (i wynik zostanie zaktualizowany w cache). Mechanizm ten działa per tabela – zmiana jednego obiektu usuwa cache wszystkich zapytań z tej tabeli (oraz kaskadowo powiązanych przez FK) (Introduction — django-cachalot 2.6.3 documentation). To prostsze podejście niż śledzenie dokładnie których zapytań dotyczył obiekt, ale gwarantujące spójność.

Przykład działania: Załóżmy, że mamy 100 artykułów w bazie. Ktoś pierwszy raz wchodzi na stronę listy artykułów – Django wykonuje SELECT * FROM articles WHERE ... i cachalot zapisuje wynik (100 rekordów). Kolejnych 50 użytkowników w ciągu następnych minut dostaje listę artykułów z cache (baza nie była pytana). Następnie dodajemy nowy artykuł (obiekt Article) – cachalot dostaje sygnał o INSERT na tabeli articles i usuwa cache związany z tą tabelą. Kolejny użytkownik, wchodząc na listę, nie znajdzie już danych w cache (bo zostały invalidowane), więc wykona się ponownie zapytanie do bazy, już pobierając 101 rekordów, i znów zapisze do cache. Dzięki temu użytkownicy nie zobaczą nigdy niekompletnej listy. Wszystko odbywa się automatycznie, bez naszego udziału.

Inne biblioteki (cache-machine, cacheops) mają nieco inne konfiguracje, ale ogólna idea jest podobna. Np. cacheops wymaga zdefiniowania w settings, które modele i na ile cachować, za pomocą słownika CACHEOPS. W zamian oferuje więcej kontroli (można cachować tylko wybrane, używać cache per model itp.). Wybór narzędzia zależy od potrzeb – django-cachalot jest bezkonfiguracyjny i świetny na początek lub dla większości projektów, cacheops daje więcej opcji dla zaawansowanych przypadków.

Najlepsze praktyki cachowania w Django

Skuteczne cachowanie to nie tylko wybór narzędzi, ale też właściwe strategie utrzymania aktualności danych i unikania problemów. Oto zestaw najlepszych praktyk, które pomogą zmaksymalizować korzyści z cache, a zminimalizować ryzyko błędów:

Projektuj cache z myślą o spójności danych: Największym wyzwaniem cachowania jest uniknięcie podawania nieświeżych danych (stale cache). Zawsze zadaj sobie pytanie: co się stanie, jeśli dane X ulegną zmianie? Czy użytkownik nadal może dostać starą wersję z cache? Zaplanuj mechanizm unieważniania. Może to być krótkie TTL (cache wygaśnie szybko samoczynnie) i/lub ręczne czyszczenie cache przy zmianach. Np. jeśli użytkownik edytuje swój profil, usuń wpis profile_{id} z cache natychmiast po zapisie. Nieświeże informacje prowadzą do niespójności i złego doświadczenia użytkownika (Enhancing Performance and Efficiency in Django Applications through Caching | MoldStud), dlatego priorytetem jest upewnienie się, że cache nie „żyje” za długo po zmianie danych.
Stosuj odpowiednie czasy życia (TTL): Ustal timeouty cache w zależności od tego, jak często dana część aplikacji się zmienia i jak krytyczna jest aktualność. Dla treści zmieniających się raz na dobę można dać cache na godzinę lub więcej. Dla danych krytycznych (np. saldo konta użytkownika) – może w ogóle nie keszować, albo kilka sekund, o ile to w ogóle potrzebne. Pamiętaj, że cache expiration to prosty i skuteczny sposób ochrony przed stale cache – po upływie TTL stara wartość jest automatycznie czyszczona (Enhancing Performance and Efficiency in Django Applications through Caching | MoldStud). Ogólna zasada: cache’uj tak długo, jak to bezpieczne, ale nie dłużej.
Wykorzystuj inwalidację cache przy zdarzeniach: Sam TTL to nie wszystko. Często lepiej reagować od razu na zdarzenie zmiany danych niż czekać na wygaśnięcie. W Django możesz podpiąć się pod sygnały post_save, post_delete modeli lub bezpośrednio po operacji w widoku, i usunąć lub zaktualizować odpowiednie wpisy cache. Np. po zapisaniu artykułu usuń cache listy artykułów (cache.delete("articles_list")). Taka inwalidacja oparta na zdarzeniach (event-based invalidation) pozwala utrzymywać cache aktualny na bieżąco (Enhancing Performance and Efficiency in Django Applications through Caching | MoldStud). Oczywiście, wymaga to, byśmy wiedzieli, które klucze powiązać z jakimi danymi. W większych projektach tworzy się czasem mapy zależności albo stosuje nazewnictwo kluczy ułatwiające grupowe unieważnianie. Przykład prostego podejścia: klucze zaczynające się od nazwy modelu, np. article_123_detail dla szczegółów artykułu 123, article_list_page1 dla listy. Gdy artykuł 123 się zmieni, usuwamy article_123_* (jego detail i może wystąpienia w listingach). To ręczna robota, ale daje precyzję.
Łącz TTL z inwalidacją dla bezpieczeństwa: Najlepiej stosować oba mechanizmy jednocześnie – gdy to możliwe. Czyli np. po zmianie danych czyścimy cache, ale i tak mamy ustawiony TTL jako zabezpieczenie, gdyby jakiś przypadek przeoczył czyszczenie. Kombinacja automatycznego wygaszania i aktywnego unieważniania zmniejsza ryzyko podania nieaktualnej informacji (Enhancing Performance and Efficiency in Django Applications through Caching | MoldStud).
Używaj “cache key versioning” przy większych zmianach: Jeśli wypuszczasz nową wersję aplikacji lub zmieniasz znacząco sposób generowania danych, warto rozważyć zmianę prefixu kluczy cache (lub użycie mechanizmu wersjonowania kluczy). Django pozwala ustawić globalny prefix (KEY_PREFIX w CACHES) – zmiana go spowoduje, że nowa wersja aplikacji będzie czytać/pisać inną pulę kluczy, izolując się od starych. To prosty sposób na cache busting przy deploymencie – nie trzeba ręcznie czyścić setek kluczy, wystarczy zmienić prefix lub wersję i stara zawartość zostaje „opuszczona” i wygaśnie naturalnie w swoim czasie. Przykładowo, podczas developmentu można do prefixu dodawać znacznik czasu startu serwera, by uniknąć odczytu starych danych (Project-wide cache prefix (low-level API) - Google Groups). W produkcji – zmiana prefixu raz na jakiś czas (lub na żądanie). Oczywiście, bez przesady – zbyt częsta zmiana prefixu to de facto ignorowanie cache (będzie budowany od nowa), ale przy dużych zmianach bywa zbawienna.
Uważaj na cache dla spersonalizowanych danych: Nigdy nie cache’uj wspólnie danych, które różnią się w zależności od użytkownika lub kontekstu, o ile klucz cache tego nie odzwierciedla. Przykład błędu: zcache’owanie całej strony po zalogowaniu pod jednym kluczem, bez rozróżnienia użytkowników – skutkować będzie pokazywaniem profilu jednego usera innym. Jeśli cache’ujesz coś związanego z profilem, zawsze dawaj np. ID użytkownika w kluczu. Django’s per-site cache domyślnie cache’uje to samo dla wszystkich – więc nie nadaje się do stron, gdzie zawartość zależy od zalogowanego usera (chyba że użyje się mechanizmu Vary on Cookie itp., ale to rzadziej). Dla bezpieczeństwa, widoki z danymi wrażliwymi oznacz @never_cache by nigdy nie trafiły do globalnego cache. Ogólna zasada: segreguj cache w zależności od wszystkich czynników wpływających na wynik (użytkownik, uprawnienia, język, urządzenie itp.). W dekoratorach i middleware pomaga w tym nagłówek Vary – np. Vary: Cookie spowoduje, że cache będzie osobny dla różnych zestawów ciastek (czyli de facto rozróżni zalogowanych), choć to obniża efektywność cache, bo wielu userów = wiele wariantów (Django Caching Strategies).
Monitoruj efektywność cache: Wprowadzenie cachowania to nie koniec pracy – warto obserwować, czy faktycznie przynosi korzyści. Używaj narzędzi takich jak Django Debug Toolbar (ma panel cache, pokazuje trafienia/missy), loguj statystyki z memcached (np. komendy get/hit/miss), monitoruj wykorzystanie pamięci. Dzięki temu zobaczysz np., że jakiś klucz nigdy nie jest trafiany (co oznacza, że być może cache TTL jest za krótki albo logika błędna), albo że masz dużo miss zaraz po wygaśnięciu – może warto wydłużyć TTL. Monitorowanie pozwala też wychwycić problemy, np. stampede (wspomniany niżej). Regularnie przeglądaj co trzymasz w cache i czy to ma sens – np. może keszujesz coś, co zajmuje mnóstwo miejsca, a nie jest często używane.
Zabezpiecz się przed „cache stampede” (nawałem odświeżania): Problem stampede pojawia się, gdy popularny element cache wygasa i nagle wiele klientów naraz zaczyna go odtwarzać. Np. masz stronę główną keszowaną co 5 minut, wygasa o 12:00 i w tej samej sekundzie 1000 użytkowników odświeża – wszystkie 1000 trafi do Django, bo cache już pusty, i zaczynają generować stronę (obciążenie x1000). Aby temu zapobiec, można zastosować kilka strategii:
- Rozłożone wygaszenie: dodawanie losowej składowej do czasu cache (np. timeout 300 ± 30 sekund), aby nie wszystko wygasało dokładnie na raz.
- Podwójny cache (double-layer): przechowywanie elementu cache z nieco dłuższym czasem w tle. Np. główny cache ustawić na 5 min, ale zachować „kopię” na 6 min. Gdy upłynie 5 min i przychodzi nowy request, serwujemy jeszcze przez chwilę starą kopię (mimo że nie najświeższa, ale powiedzmy akceptowalna), jednocześnie asynchronicznie odświeżamy właściwy cache. Biblioteki takie jak django-cacheback realizują ten wzorzec – odświeżają wygasły cache w tle, serwując lekko przeterminowane dane zamiast obciążać aplikację lawinowo (DRF caching views and invalidating cached once an object changes) (codeinthehole/django-cacheback: Smart caching for ... - GitHub).
- Blokada podczas regeneracji: przy krytycznych sekcjach można zastosować mechanizm lock – pierwszy wątek, który stwierdzi brak cache, ustawia blokadę (np. wpis w cache „X_lock”) i zaczyna generować dane, reszta w tym czasie czeka parę sekund lub dostaje starszą wersję. Po wygenerowaniu, pierwszy odświeża cache i zwalnia lock, reszta może pobrać nowe dane. To komplikuje kod, ale zapobiega np. 100 jednoczesnym ciężkim zapytaniom do bazy.
Unikaj nadmiernego zagnieżdżania i duplikowania cache: Choć warstwy cache są wskazane, uważaj by nie keszować tego samego na kilku poziomach niepotrzebnie, co utrudni unieważnianie. Np. jeśli używasz django-cachalot, to i tak pewne powtarzalne zapytania się cache’ują, więc może nie musisz już ręcznie cache’ować wyników tych zapytań w kodzie – bo to dublowanie. Z drugiej strony, cache różnych poziomów może dotyczyć różnych aspektów (jeden odciąży bazę, inny skróci render HTML). Klucz to świadomie zarządzać, co gdzie jest przechowywane. Dokumentuj (choćby w komentarzach), że np. “To pole jest cache’owane w memcached pod kluczem X na 10 min”.
Czyść globalny cache przy istotnych zmianach: Jeśli zdarzy Ci się wprowadzić błąd skutkujący zapisaniem niepoprawnych danych do cache, lub zauważysz że jakaś część jest nieaktualna, nie wahaj się wyczyścić cache (np. uruchamiając cache.clear() w shellu Django lub flush w narzędziu do memcached/redis). Lepiej przez chwilę obciążyć bazę niż serwować błędne informacje. Oczywiście, to sytuacja awaryjna – lepiej zapobiegać niż leczyć poprzez dobre mechanizmy unieważniania. Ale warto pamiętać, że taka opcja istnieje. W bibliotekach ORM cache (cachalot, cacheops) są też funkcje do czyszczenia ich cache (np. invalidate_all w cachalot (Quick start — django-cachalot 2.6.3 documentation)).

Podsumowując: najlepsze praktyki cachowania sprowadzają się do równowagi między wydajnością a aktualnością danych. Z jednej strony chcemy maksymalnie odciążyć system poprzez cache, z drugiej – musimy zapewnić poprawność i świeżość informacji. Świadome ustawianie TTL, aktywne unieważnianie przy zmianach, pilnowanie kluczy i warunków cache, a także monitorowanie działania – to wszystko składa się na zdrowe wykorzystanie cache. Pamiętajmy też słynne powiedzenie, że cache invalidation to jeden z dwóch trudnych problemów w informatyce (obok nazywania rzeczy) (python - Why is Django returning stale cache data? - Stack Overflow) – dlatego należy poświęcić mu należytą uwagę przy implementacji.

Wyzwania i typowe problemy z cachowaniem

Mimo licznych zalet, cachowanie niesie ze sobą pewne wyzwania. Warto znać typowe problemy, by móc im zapobiegać lub je rozwiązywać:

Nieświeże dane (stale cache): Jak już wielokrotnie podkreślano, największe ryzyko to podawanie użytkownikom nieaktualnych informacji z cache. Może to być skutkiem błędnego mechanizmu unieważniania lub przeoczenia, że jakiś fragment powinien zostać odświeżony. Symptomy to np. użytkownik edytuje coś, a nadal widzi starą wersję; nowy komentarz nie pojawia się, bo strona jest w cache; produkt wyprzedany wciąż widnieje jako dostępny. Rozwiązaniem jest dopracowanie strategii cache invalidation – upewnienie się, że przy każdej zmianie danych odpowiednie wpisy są czyszczone lub bardzo krótko żyją. Trzeba też uważać na wiele poziomów cache – np. odświeżamy cache w Django, ale zapomnieliśmy, że CDN nadal trzyma starą wersję. Wtedy albo integrujemy to (np. wysyłamy tzw. PURGE do Varnisha/CDN po zmianie ważnych danych), albo zmniejszamy TTL na poziomie CDN dla takich zasobów.
Błędy spowodowane kolizją kluczy: Jeśli używamy cache ręcznie, łatwo o błąd, gdzie dwa różne miejsca w aplikacji użyją tego samego klucza dla różnych danych. W efekcie jedno może nadpisać dane drugiego lub odczytać nie to co trzeba. Aby tego uniknąć, stosuj unikatowe nazewnictwo kluczy – np. poprzedzaj klucze nazwą aplikacji lub funkcji. Django częściowo to robi automatycznie (np. per-site cache używa pełnego URL, per-view też, fragment cache – klucz od nazwy fragmentu), ale przy własnych kluczach musimy sami tego dopilnować.
Nadmierne zużycie pamięci i wyrzucanie danych: Cache w pamięci RAM (Memcached, Redis) ma ograniczoną pojemność, np. 1 GB. Jeśli spróbujemy włożyć tam więcej danych, starsze wpisy zostaną usunięte (polityką LRU lub inną). Może się zdarzyć, że intensywnie cache’ujemy tak dużo (lub tak duże obiekty), że ważne dane szybko wylatują z cache, czyniąc go mniej skutecznym. Problemem może być też równomierność kluczy – np. generujemy klucze zależne od usera i mamy ich milion, z czego każdy user raz na rok zajrzy – w efekcie cache zapełniony jest masą rzadko używanych danych kosztem tych popularnych. Rozwiązania:
- Monitoruj wykorzystanie pamięci cache i rozmiary obiektów. Bardzo duże obiekty może lepiej serializować inaczej lub dzielić.
- Ustaw rozsądne czasy życia – wpisy które nie będą potrzebne długo niech szybko wygasają, robiąc miejsce.
- Ewentualnie rozważ powiększenie pojemności lub rozbicie cache na segmenty (np. oddzielny cluster redis dla cache stron, inny dla sesji, itp.).
- Sprawdź politykę eviction (Memcached i Redis domyślnie LRU – usuwa najdawniej używane; to zwykle ok). Jeśli jakieś klucze są krytyczne, można w Redis oznaczać je jako niewyswapywalne (volatile vs noeviction), ale to ryzykowne – raczej staraj się zmieścić w RAM.
Rozproszone środowisko – spójność między instancjami: W aplikacjach z wieloma serwerami aplikacyjnymi, ważne jest by korzystały one ze wspólnego cache. Jeśli przez pomyłkę jedna instancja używa innego backendu (np. lokalnego), a inna innego, to użytkownicy mogą trafiać na różne wersje danych zależnie od tego, który serwer obsłużył żądanie. Dlatego standardem jest korzystanie z centralnego Memcached/Redis – co zapewnia spójność. Innym aspektem jest replikacja cache w skali geograficznej – np. dwie serwerownie, każda z własnym cache bliżej użytkowników. Wtedy trzeba przemyśleć mechanizm synchronizacji lub zaakceptować, że dane mogą chwilę różnić się między regionami (często akceptowalne). Problemy z replikacją mogą też dotyczyć np. Redis cluster – jeśli nie skonfigurujemy dobrze, może nieprawidłowo rozgłaszać invalidacje (to raczej rzadkie przy typowym użyciu jako cache, bo tam flush jest globalny).
Błędy logiczne w warunkach wyścigowych: To dotyczy wspomnianego cache stampede i ogólnie sytuacji, gdy wiele procesów jednocześnie manipuluje cache. Przykład: Dwa zapytania przychodzą w tym samym mikroczasie, oba widzą pusty cache i wykonują drogą operację, potem obie zapisują (ostatnia wygrywa). Może to nie problem, bo i tak rezultat ten sam, tylko zmarnowano podwójnie zasoby. Gorzej, gdy stan w międzyczasie się zmienia – np. dwa procesy liczą tę samą rzecz, ale na podstawie niezsynchronizowanych danych. Takie sytuacje są rzadkie, ale trzeba je mieć na uwadze. Rozwiązaniem bywają zamki (locks), np. korzystając z funkcji cache.add() – która ustawia wartość tylko jeśli nie było klucza. Można użyć jej by jeden proces zapisał np. "generuję klucz X" i drugi już nie generował. Albo użyć mechanizmu blokad Redisa. Te dodatkowe mechanizmy komplikują implementację, dlatego stosuj je tylko tam, gdzie rzeczywiście obserwujesz problem lub w scenariuszach dużego ruchu na granicy wygaśnięcia cache.
Błędy konfiguracji i pominięcie cache: Czasem zdarza się, że cache jest poprawnie zaimplementowany w kodzie, ale… nie działa z powodu błędu konfiguracji. Np. nie uruchomiliśmy memcached, więc Django automatycznie przeszedł na DummyCache (który nic nie cache’uje). Albo błąd w adresie serwera sprawia, że każde wywołanie cache kończy się wyjątkiem (który być może połykamy). Warto upewnić się w logach, że cache jest faktycznie używany. Dobrze jest też obsłużyć ewentualną niedostępność cache (np. memcached padł) – Django wtedy zwróci None na get albo rzuci wyjątek przy set? Z reguły cache Django jest odporny – zwróci None jak nie ma, i po prostu nie zapisze jak nie może – ale zależy od backendu i konfiguracji. Bezpiecznie jest założyć, że cache może czasem nie działać i aplikacja nadal powinna poprawnie funkcjonować (tylko wolniej). Czyli design for cache failures – np. nie opieraj logiki krytycznej na tym, że coś musi być w cache; zawsze przewiduj, co zrobić gdy cache miss (np. ponownie policzyć).
Problemy specyficzne dla określonych narzędzi: Każde narzędzie cache ma swoje niuanse. Np. Memcached ma limit rozmiaru obiektu ~1MB – większych nie zapisze (można skompresować przed, są pluginy do django-redis co auto-kompresują duże obiekty). Redis w domyślnej konfiguracji może blokować przy snapshotach bazy (stop-the-world fork) – co przy użyciu czysto cache nie jest częste, bo raczej RDB off, ale warto wiedzieć. Varnish domyślnie ignoruje query parameters, jeśli nie powiemy mu inaczej – więc może cache’ować coś z parametrami błędnie jako jedno. Trzeba więc znać narzędzia i ich konfigurację, by uniknąć niespodzianek.

Podsumowując tę sekcję: cachowanie przyspiesza aplikację kosztem dodatkowej złożoności. Typowe błędy wynikają z tej złożoności – coś przeoczymy, nie przewidzimy jakiegoś scenariusza i cache może wtedy działać przeciwko nam (serwując złe dane lub wcale nie pomagając). Dlatego implementując cache, należy robić to krok po kroku, testować różne sytuacje (czy po edycji na pewno widać zmianę? czy po wygaśnięciu nie ma chwilowego spowolnienia? itd.) i być przygotowanym na tunning parametrów. Dobrze zaimplementowany cache będzie przezroczysty dla użytkownika (poza tym, że szybciej 😉), a odczuwalny dla serwera (mniejsze zużycie CPU/DB).

Django-Cachalot (biblioteka Cachelot) – automatyczny cache ORM

Na koniec przyjrzyjmy się bliżej wspomnianej już bibliotece django-cachalot, nazywanej czasem potocznie Cachelot. Jest to popularne rozwiązanie do automatycznego cache’owania zapytań Django ORM. Warto wiedzieć, co oferuje i kiedy jego użycie ma sens.

Co to jest django-cachalot? Jest to open-source’owa biblioteka, którą dodaje się jako aplikację Django, a która przechwytuje wszystkie odczytujące zapytania SQL generowane przez ORM i zapisuje ich wyniki w cache. Działa z Django 1.7+ wzwyż (wspiera nawet najnowsze wersje). Po dodaniu do INSTALLED_APPS, praktycznie każdy SELECT na bazie idący przez Django ORM będzie potencjalnie keszowan (Debian -- Details of package python-django-cachalot-doc in sid)】. Django-cachalot monitoruje również transakcje zapisu – jeśli wykryje zmiany danych, automatycznie unieważnia powiązane wpisy cache, aby nie doszło do nieświeżych odczytó (Debian -- Details of package python-django-cachalot-doc in sid)】. To, co wyróżnia cachalot, to że robi to w sposób dość bezinwazyjny dla dewelopera – nie trzeba nigdzie w kodzie stosować specjalnych querysetów czy managerów (jak to jest w cache-machine). Działa to globalnie, “pod spodem”.

Zalety użycia django-cachalot:

Łatwy zysk wydajności: Włączenie cachalot może przyspieszyć wiele widoków bez żadnych zmian w ich implementacji. Jak głosi dokumentacja, „to idealne przyspieszenie dla większości projektów Django – im więcej odwiedzających, tym strona staje się szybsza, bo wszystkie możliwe zapytania SQL ostatecznie lądują w cache (Introduction — django-cachalot 2.6.3 documentation)】. Często w Django wiele czasu generowania strony to właśnie multiple round-trips do bazy danych – ograniczenie ich przez cache potrafi przynieść kilkukrotne zwiększenie przepustowości. Zwłaszcza admin Django dużo zyskuje, bo czyni mnóstwo powtarzalnych zapyta (Introduction — django-cachalot 2.6.3 documentation)】.
Automatyczna invalidacja: Cachalot dba o spójność danych – nie musimy się bać stale cache. Kiedy tylko zmienimy coś w bazie przez Django (ORM), odpowiednie cache zostaną wyczyszczone. Biblioteka zapewnia, że nigdy nie dostaniemy starych wyników – to jej założeni (Introduction — django-cachalot 2.6.3 documentation)】. Robi to, jak wspomniano, per tabela: zmiana obiektu oznacza wyczyszczenie wszystkiego co dotyczy tej tabeli. Jest to podejście konserwatywne, ale pewne. Autorzy świadomie odrzucili cache per obiekt jako zbyt ryzykowny (trudno wykryć wszystkie zależności poprawnie (Introduction — django-cachalot 2.6.3 documentation)】. Dzięki temu cachalot jest bezpieczny w użyciu – nie musimy mnożyć warunków kiedy użyć a kiedy nie (poza częstotliwością zmian, o czym za chwilę).
Wsparcie zaawansowanych zapytań: Biblioteka obsługuje praktycznie wszystkie operacje ORM – w tym skomplikowane zapytania, select_related, prefetch_related, agregacje, subquery itp. (nie cache’uje tylko tych, które zmieniają dane oczywiście). Dzięki temu możemy jej użyć nawet w dużych projektach bez strachu, że coś nie zadziała. Jest też stale rozwijana i dostosowywana do nowych wersji Django. W porównaniu do alternatyw, uchodzi za bardzo stabilną i bezproblemową.
Konfigurowalność: Mimo że działa automatycznie, oferuje ustawienia typu: możliwość wyłączenia cache dla niektórych tabel (np. bardzo zmiennych), możliwość użycia innego aliasu cache (niż default), czy nawet czasowego wyłączenia cache (przez context manager) np. na czas migracji danych. Większość jednak nie wymaga zmian konfiguracji – out of the box jest ok.
Dobre rezultaty w typowych aplikacjach: Z doświadczeń użytkowników wynika, że projekty z ruchem rzędu kilkadziesiąt-kilkaset tysięcy odsłon miesięcznie (czyli dość typowe średnie strony) działają świetnie z cachalot i odczuwają znaczący spadek obciążenia D (Introduction — django-cachalot 2.6.3 documentation)】. Jego wydajność jest tym lepsza, im więcej jest powtórzeń tych samych zapytań. Jeśli np. każdy user wchodzi na stronę główną i ta strona robi 5 pewnych zapytań – to przy 100 użytkownikach zamiast 500 zapytań do DB może być 5 (reszta z cache). Nawet przy częstszych zapisach, cachalot stara się je obsłużyć wydajnie – pierwsze zapytanie po wyczyszczeniu jest trochę wolniejsze (bo musi i tak wykonać SQL + zapisać cache), ale i tak średnio system zyskuje więcej na wielokrotnych odczytach.

Kiedy (i kiedy nie) używać django-cachalot:

Najważniejsze kryterium to charakterystyka obciążenia bazy. Jeśli Twój projekt to głównie czytanie danych z bazy, a zapisy są rzadkie lub umiarkowane, cachalot prawdopodobnie bardzo Ci pomoże. Przykłady: strony z treściami, fora dyskusyjne (gdzie czyta się znacznie więcej niż pisze), systemy CMS, aplikacje typu katalog produktów (częste przeglądanie, rzadsze aktualizacje). W takich sytuacjach uzyskasz znaczące przyspieszenie odpowiedzi i odciążenie bazy praktycznie bez kodowania manualnego cache.

Z drugiej strony, jeśli masz bardzo dużo zapisów – np. czat na żywo, giełdę transakcji, stronę społecznościową gdzie co minutę ktoś dodaje dziesiątki rekordów – to cachalot może się okazać niewydajny. Będzie wtedy ciągle cache’ował i unieważniał te same tabele. Dokumentacja jasno mówi, że przy >50 modyfikacjach na minutę na tabelę, korzyści mogą się zatrze (django-cachalot — django-cachalot 2.6.3 documentation)】. W takim przypadku najpierw upewnij się, że baza wydala – optymalizuj zapytania, używaj indeksów, sharding itd., bo cache tak dynamicznych danych bywa trudny. Możesz też rozważyć alternatywy, np. django-cache-machine, który cache’uje pojedyncze obiekty (mniej do unieważniania naraz (django-cachalot — django-cachalot 2.6.3 documentation)】, choć on z kolei ma inne wady i też nie jest cudowny przy tylu zmianach.

Innym powodem, by nie używać takiej biblioteki, jest prostota projektu. Jeśli Twoje strony i tak generują się w ułamku sekundy, a obciążenie DB jest niskie, to dokładanie kolejnej warstwy (z potencjalnymi własnymi bugami) może nie być warte zachod (Introduction — django-cachalot 2.6.3 documentation)】. Kiedy indziej – gdy już masz zaimplementowane własne mechanizmy cache tu i ówdzie, cachalot może dublować pracę albo komplikować debugowanie (bo np. będzie cache’ować też te rzeczy, które Ty cache’ujesz i jak coś jest nie tak, trudniej dojść czy problem z Twoim cache czy z cachalot).

Generalnie jednak, dla większości typowych projektów Django, które zaczynają odczuwać load na bazie przy rosnącym ruchu, django-cachalot jest znakomitym narzędziem do szybkiej poprawy wydajności. Jego zalety to minimalna ingerencja w kod i duży efekt, wady – to większe zużycie pamięci na trzymanie kopii danych z bazy oraz ewentualne opóźnienia przy bardzo intensywnych zapisach.

Warto dodać, że istnieją wspomniane alternatywy: django-cacheops jest bardziej skomplikowany, ale pozwala np. cache’ować z finezją (tylko wybrane modele, z opcją cache pojedynczych obiektów, ma też fajne funkcje jak invalidation poprzez sygnały zewnętrzne). Johnny Cache (mniej rozwijany obecnie) i cache-machine były popularne kilka lat temu. Z kolei django-cacheback to inny pomysł – cache’owanie z automatycznym odświeżaniem w tle, aby nigdy nie podać bardzo starej wartości (wykorzystuje Celery/RQ do background refresh (DRF caching views and invalidating cached once an object changes)】. Jednak do większości zastosowań cachalot jest w sam raz.

Podsumowanie django-cachalot: To biblioteka typu “plug and play”, która przyspieszy niemal każdą aplikację Django opartą na bazie SQL bez większego wysiłku. Należy używać jej świadomie – wiedząc, że cache invalidation odbywa się globalnie na tabelę – więc przy częstych zmianach efektywność spada. Jeśli Twoja aplikacja spełnia założenia (przewaga odczytów, umiarkowane zmiany), cachalot może zredukować obciążenie bazy nawet o 70-80% i sprawić, że strona pod dużym ruchem będzie działać płynnie (Enhancing Performance and Efficiency in Django Applications through Caching | MoldStud) (Enhancing Performance and Efficiency in Django Applications through Caching | MoldStud)】. Włączenie go jest proste, a potencjalne wyłączenie również (w razie problemów można usunąć z INSTALLED_APPS lub ustawić CACHALOT_ENABLED=False).

Na koniec warto przypomnieć, że cachowanie jest jedną z najskuteczniejszych technik optymalizacyjnych, ale musi być stosowane rozważnie. Django daje nam do ręki potężne narzędzia cache na różnych poziomach – wykorzystujmy je tam, gdzie to ma sens. Pamiętajmy o utrzymaniu świeżości danych i testowaniu zachowania aplikacji po wprowadzeniu cache. Dobrze skonfigurowany cache może znacząco poprawić wydajność (krótszy czas odpowiedzi, więcej obsłużonych użytkowników na tym samym sprzęcie (Django Caching Strategies) (Django Caching Strategies)】 i nawet poprawić SEO (szybsza strona jest lepiej oceniana przez Google (Django Caching Strategies)】. Miejmy jednak zawsze z tyłu głowy, że nad cache trzeba panować – aby nie stał się źródłem trudnych do debugowania błędów. Z tą wiedzą i praktykami opisanymi powyżej, można śmiało wdrażać cachowanie w projektach Django, ciesząc się zarówno szybkością działania, jak i poprawnością danych.

Źródła:

JBS Dev – Django Caching Strategies: Omówienie warstw cache (upstream, downstream, ORM, fragmenty) i zalety cachowania warstwoweg (Django Caching Strategies) (Django Caching Strategies)】.
Django Documentation – Django’s cache framework: Oficjalna dokumentacja cache w Django (konfiguracja, usage, middleware, dekoratory (Django’s cache framework | Django documentation | Django) (Django’s cache framework | Django documentation | Django)】.
Robin Winslow – Django HTTP headers: controlling caching: Wprowadzenie do sterowania cache przeglądarki za pomocą nagłówków w Djang (Django HTTP headers: Controlling caching on cn.ubuntu.com) (Django HTTP headers: Controlling caching on cn.ubuntu.com)】.
Stack Overflow – Memcached vs Redis?: Porównanie Memcached i Redis jako cache (wydajność, możliwości, rekomendacje (caching - Memcached vs. Redis? - Stack Overflow) (caching - Memcached vs. Redis? - Stack Overflow)】.
MoldStud – Boost Django performance with caching: Artykuł o strategiach cachowania, m.in. o znaczeniu unieważniania i wygaszania cache dla spójności danyc (Enhancing Performance and Efficiency in Django Applications through Caching | MoldStud) (Enhancing Performance and Efficiency in Django Applications through Caching | MoldStud)】.
Django-cachalot Documentation: Opis działania django-cachalot (automatyczny cache zapytań, invalidacja przy zmianach) oraz rekomendacje kiedy używa (Debian -- Details of package python-django-cachalot-doc in sid) (Introduction — django-cachalot 2.6.3 documentation)】.
Stack Overflow – Why is Django returning stale cache data?: Dyskusja o problemie nieświeżych danych i trudności cache invalidatio (python - Why is Django returning stale cache data? - Stack Overflow)】.
Django Dev. Forum/Cacheops docs: Inne uwagi dot. cache (mechanizmy flush lists, cache stampede, itp. (python - Why is Django returning stale cache data? - Stack Overflow) (codeinthehole/django-cacheback: Smart caching for ... - GitHub)】.