Django innehåller ett flexibelt cachningsramverk som stöder flera nivåer av cachning (hela sidor, vyresultat, mallmallar eller godtycklig data) och flera backends (minnesintern, Redis, Memcached, databas). Cachning undviker att upprepa dyrt arbete — en av de högsta effektens prestandaoptimiseringar.
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 låter dig cacha på flera granularitetsnivåer: hela sidor (cache_page), mallmallar ({% cache %}), och godtycklig data via low-level API (cache.get/cache.set — det flexibla get-or-compute-mönstret). Det finns även hel-site-cachning 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)
Cachning är en av de högsta effektens prestandaoptimiseringar för Django-applikationer, och ramverkets omfattande, flernivå-cachningsystem gör det tillgängligt — förståelse för det är värdefull kunskap på seniornivå för att bygga snabba, skalbara applikationer.
Kärnvärdet är att undvika upprepad dyrt arbete: databasfrågor, komplexa beräkningar, externa API-anrop och mallrendering kan cachas så att efterföljande förfrågningar betjänas snabbt, vilket dramatiskt minskar latensen och databasens/serverbelastningen.
Djangos flexibilitet över flera cachningsnivåer (hela sidor med cache_page, mallmallar med {% cache %}, och godtycklig data via low-level APIs get-or-compute-mönster) låter dig cacha på exakt rätt granularitet för varje situation, och dess anslutbara backends (särskilt Redis för en delad cache över flera servrar — viktigt eftersom cacher i minnet per process inte delas vid horisontell skalning) passar olika distributionsbehov.
Att veta hur man konfigurerar cachning, väljer rätt nivå och väljer rätt backend för distributionen är praktisk, ofta-behövd kunskap.
Lika viktigt är att förstå cachningens central svårighet — invalidering (det berömt svåra problemet att rensa eller uppdatera cachad data när underliggande data ändras, via TTLs, explicit borttagning vid skrivningar eller nyckelversionering, för att undvika att servera föråldrad data) — eftersom att få detta fel är det klassiska cachningsfelet som visar användare föråldrad information.
Också att veta vad du ska cacha (dyrt, sällan föränderligt data) kontra vad du inte ska (mycket dynamisk eller känslig data) är nyckeln till effektiv cachningsanvändning.
Eftersom cachning levererar större prestandavinster men kräver noggrann invalidering, är det att bemästra Djangos cachningsramverk — nivåerna, backends och särskilt invalideringsstrategierna — viktig kunskap för att bygga presterande, skalbara applikationer och ett kännetecken för utvecklare som kan få Django-appar snabba under verklig belastning.