Django include un framework de caching flexibil care suportă mai multe niveluri de caching (pagini întregi, rezultate de view, fragmente de template, sau date arbitrare) și mai multe backend-uri (in-memory, Redis, Memcached, bază de date). Caching-ul evită repetarea unor operații costisitoare — una dintre cele mai impactante optimizări de performanță.
CACHES = {
: {
: ,
: ,
}
}
# 1. Per-view caching — cache an entire view's output
from django.views.decorators.cache import cache_page
@cache_page(60 * 15) # cache this view's response for 15 minutes
def article_list(request):
...
<!-- 2. Template fragment caching — cache part of a template -->
{% load cache %}
{% cache 500 sidebar %}
... expensive sidebar rendering ... <!-- cached for 500 seconds -->
{% endcache %}
# 3. Low-level cache API — cache ANY data, full control
from django.core.cache import cache
def get_stats():
stats = cache.get("dashboard_stats") # check cache first
if stats is None: # cache MISS
stats = compute_expensive_stats() # do the work
cache.set("dashboard_stats", stats, 3600) # store for 1 hour
return stats
Django te permite să faci cache la mai multe niveluri de granularitate: pagini întregi (cache_page), fragmente de template ({% cache %}), și date arbitrare via API-ul low-level (cache.get/cache.set — pattern-ul flexibil de get-or-compute). Există de asemenea caching-ul full-site via middleware.
# when underlying data changes, the cache must be updated or cleared, or users see stale data
def update_article(article):
article.save()
cache.delete("article_list") # invalidate affected cache entries
# strategies: TTL (accept brief staleness), explicit deletion on writes, versioned keys,
# or signals to invalidate on model save/delete
Cache invalidation is the classic hard problem: when data changes, stale cached
values must be cleared/refreshed. Approaches: short TTLs (accept some staleness),
explicit cache.delete on writes, or cache versioning/key schemes.
✓ Expensive queries/computations, rendered pages/fragments that change infrequently
✓ Aggregations, external API responses, session data
✗ Highly personalized or rapidly-changing data (or use very short TTLs / vary per user)
✗ Don't cache sensitive data carelessly (consider who can read the cache)
Caching-ul este una dintre cele mai impactante optimizări de performanță pentru aplicațiile Django, iar sistemul de caching cuprinzător și multi-nivel al framework-ului îl face accesibil — înțelegerea lui este cunoștință valoroasă de nivel senior pentru construirea unor aplicații rapide și scalabile.
Valoarea esențială constă în evitarea repetării unor operații costisitoare: query-urile bazei de date, calculele complexe, apelurile API externe și rendering-ul template-urilor pot fi cached astfel încât cererile ulterioare să fie servite rapid, reducând dramatic latența și încărcarea bazei de date/serverului.
Flexibilitatea Django-ului pe mai multe niveluri de caching (pagini întregi cu cache_page, fragmente de template cu {% cache %}, și date arbitrare via pattern-ul get-or-compute al API-ului low-level) te permite să faci cache exact la granularitatea potrivită pentru fiecare situație, iar backend-urile sale pluggable (mai ales Redis pentru un cache partajat pe mai multe servere — important deoarece cache-urile in-memory per-proces nu sunt partajate la scalare orizontală) se potrivesc diferitelor nevoi de deployment.
Cunoașterea cum să configurezi caching-ul, cum să alegi nivelul potrivit și cum să selectezi backend-ul potrivit pentru deployment este cunoștință practică, frecvent necesară.
La fel de important este înțelegerea dificultății centrale a caching-ului — invalidarea (problema faimoasă a ștergerii sau reîmprospătării datelor cached atunci când datele subiacente se schimbă, via TTL-uri, ștergere explicită la scrierea datelor, sau versionarea cheilor, pentru a evita servirea datelor expirate) — deoarece a greși în asta este eșecul clasic al caching-ului care arată utilizatorilor informații vechi.
De asemenea, cunoașterea ce să faci cache (date costisitoare, rar modificate) versus ce nu (date extrem de dinamice sau sensibile) este esențială pentru a folosi caching-ul efectiv.
Deoarece caching-ul oferă câștiguri majore de performanță dar necesită invalidare atentă, stăpânirea framework-ului de caching Django — nivelurile, backend-urile și mai ales strategiile de invalidare — este cunoștință importantă pentru construirea unor aplicații performante, scalabile și o caracteristică a dezvoltatorilor care pot face aplicațiile Django rapide sub încărcare reală.