Django jinkludi framework ta' caching flessibli li jappoġġja livelli multipli ta' caching (paġni sħiħa, riżultati ta' views, frammenti ta' templates, jew data arbitrarja) u backends multipli (fi-memorja, Redis, Memcached, database). Il-caching jevita li trepetiru xogħol għalì — waħda mill-aktar ottimizzazzjonijiet ta' prestazzjoni ta' impatt għoli.
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 jippermettik li tacċettja cache f'granularitajiet multipli: paġni sħiħa (cache_page), frammenti ta' templates ({% cache %}), u data arbitrarja permezz tal-API ta' livell baxxi (cache.get/cache.set — il-pattern flessibli get-or-compute). Hemm ukoll full-site caching permezz ta' 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)
Il-caching huwa waħda mill-aktar ottimizzazzjonijiet ta' prestazzjoni ta' impatt għoli għal applikazzjonijiet Django, u s-sistema komprehensiva ta' caching multi-livell tal-framework tagħmilha aċċessibli — il-fehim tagħha huwa għarifa ta' livell seniour valida biex tinbena applikazzjonijiet veloċi u scalable.
il-valur ewlieni huwa l-evitar ta' xogħol għalì ripetut: queries ta' database, computazzjonijiet kumplessi, sejħat ta' API esterni, u rendering ta' templates jistgħu jkunu cached sabiex il-requests sussegwenti jiġu servuti malajr, u b'hekk jitnaqqsu drastikament il-latency u l-load tal-database/server. \