---
title: "Djangos ramverk för cache"
version: 6.0
locale: sv
source: https://docs.djangoproject.com/sv/6.0/topics/cache/
canonical: https://djangodocs.dev/sv/6.0/topics/cache/
---
# Djangos ramverk för cache

En grundläggande avvägning när det gäller dynamiska webbplatser är att de är just dynamiska. Varje gång en användare begär en sida gör webbservern alla möjliga beräkningar - från databasfrågor till mallåtergivning till affärslogik - för att skapa den sida som besökaren på din webbplats ser. Det här är mycket dyrare, sett ur ett processoverheadperspektiv, än en standardserver som läser en fil från filsystemet.

For most web applications, this overhead isn’t a big deal. Most web
applications aren’t `washingtonpost.com` or `slashdot.org`; they’re
small-to medium-sized sites with so-so traffic. But for medium- to high-traffic
sites, it’s essential to cut as much overhead as possible.

Det är där cachelagring kommer in i bilden.

Att cachelagra något är att spara resultatet av en dyr beräkning så att du inte behöver utföra beräkningen nästa gång. Här är lite pseudokod som förklarar hur detta skulle fungera för en dynamiskt genererad webbsida:

```text
given a URL, try finding that page in the cache
if the page is in the cache:
    return the cached page
else:
    generate the page
    save the generated page in the cache (for next time)
    return the generated page
```

Django levereras med ett robust cachesystem som låter dig spara dynamiska sidor så att de inte behöver beräknas för varje begäran. För enkelhetens skull erbjuder Django olika nivåer av cachegranularitet: Du kan cachelagra resultatet av specifika vyer, du kan cachelagra endast de delar som är svåra att producera, eller du kan cachelagra hela din webbplats.

Django fungerar också bra med ”nedströms” cacher, till exempel [Squid](http://www.squid-cache.org/) och webbläsarbaserade cacher. Det här är de typer av cacheminnen som du inte direkt kontrollerar men som du kan ge ledtrådar (via HTTP-rubriker) om vilka delar av din webbplats som ska cachas och hur.

> **See also**
>
> I [Cache Framework design philosophy](/sv/6.0/misc/design-philosophies/#cache-design-philosophy) förklaras några av ramverkets designbeslut.

## Uppsättning av cachen

Cachesystemet kräver en liten del inställningar. Du måste nämligen tala om var dina cachade data ska finnas - om det är i en databas, på filsystemet eller direkt i minnet. Det här är ett viktigt beslut som påverkar cachens prestanda; ja, vissa cachetyper är snabbare än andra.

Dina cachepreferenser anges i inställningen [`CACHES`](/sv/6.0/ref/settings/#std-setting-CACHES) i din inställningsfil. Här följer en förklaring av alla tillgängliga värden för [`CACHES`](/sv/6.0/ref/settings/#std-setting-CACHES).

### Memcached

[Memcached](https://memcached.org/) är en helt minnesbaserad cache-server som ursprungligen utvecklades för att hantera höga belastningar på LiveJournal.com och därefter open-sourcades av Danga Interactive. Den används av webbplatser som Facebook och Wikipedia för att minska databasåtkomsten och dramatiskt öka webbplatsens prestanda.

Memcached körs som en daemon och tilldelas en viss mängd RAM-minne. Allt den gör är att tillhandahålla ett snabbt gränssnitt för att lägga till, hämta och ta bort data i cacheminnet. All data lagras direkt i minnet, så det finns ingen overhead för databas- eller filsystemanvändning.

Efter att ha installerat Memcached själv måste du installera en Memcached-bindning. Det finns flera Python Memcached-bindningar tillgängliga; de två som stöds av Django är [pylibmc](https://pypi.org/project/pylibmc/) och [pymemcache](https://pypi.org/project/pymemcache/).

Att använda Memcached med Django:

- Ställ in [`BACKEND`](/sv/6.0/ref/settings/#std-setting-CACHES-BACKEND) till `django.core.cache.backends.memcached.PyMemcacheCache` eller `django.core.cache.backends.memcached.PyLibMCCache` (beroende på vilken memcached-bindning du har valt)
- Ställ in [`LOCATION`](/sv/6.0/ref/settings/#std-setting-CACHES-LOCATION) till `ip:port`-värden, där `ip` är IP-adressen för Memcached-daemon och `port` är den port som Memcached körs på, eller till ett `unix:path`-värde, där `path` är sökvägen till en Memcached Unix-socketfil.

I det här exemplet körs Memcached på localhost (127.0.0.1) port 11211, med bindningen `pymemcache`:

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

I det här exemplet är Memcached tillgängligt via en lokal Unix-socketfil `/tmp/memcached.sock` med bindningen `pymemcache`:

```
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",
        "LOCATION": "unix:/tmp/memcached.sock",
    }
}
```

En utmärkt funktion hos Memcached är dess förmåga att dela en cache över flera servrar. Det innebär att du kan köra Memcached-daemoner på flera maskiner och programmet kommer att behandla gruppen av maskiner som en *enkel* cache, utan att behöva duplicera cache-värden på varje maskin. För att dra nytta av den här funktionen måste du inkludera alla serveradresser i [`LOCATION`](/sv/6.0/ref/settings/#std-setting-CACHES-LOCATION), antingen som en semikolon- eller kommaseparerad sträng eller som en lista.

I det här exemplet delas cachen mellan Memcached-instanser som körs på IP-adresserna 172.19.26.240 och 172.19.26.242, båda på port 11211:

```
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",
        "LOCATION": [
            "172.19.26.240:11211",
            "172.19.26.242:11211",
        ],
    }
}
```

I följande exempel delas cacheminnet mellan Memcached-instanser som körs på IP-adresserna 172.19.26.240 (port 11211), 172.19.26.242 (port 11212) och 172.19.26.244 (port 11213):

```
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",
        "LOCATION": [
            "172.19.26.240:11211",
            "172.19.26.242:11212",
            "172.19.26.244:11213",
        ],
    }
}
```

Som standard ställer backend `PyMemcacheCache` in följande alternativ (du kan åsidosätta dem i din [`OPTIONS`](/sv/6.0/ref/settings/#std-setting-CACHES-OPTIONS)):

```
"OPTIONS": {
    "allow_unicode_keys": True,
    "default_noreply": False,
    "serde": pymemcache.serde.pickle_serde,
}
```

En sista punkt om Memcached är att minnesbaserad cachelagring har en nackdel: eftersom den cachelagrade datan lagras i minnet kommer datan att gå förlorad om din server kraschar. Det är uppenbart att minnet inte är avsett för permanent datalagring, så lita inte på minnesbaserad cachning som din enda datalagring. Utan tvekan bör \* ingen \* av Djangos cachelagringsbackends användas för permanent lagring - de är alla avsedda att vara lösningar för cachelagring, inte lagring - men vi påpekar detta här eftersom minnesbaserad cachelagring är särskilt tillfällig.

### Redis

[Redis](https://redis.io/) är en databas i minnet som kan användas för cachelagring. För att börja behöver du en Redis-server som körs antingen lokalt eller på en fjärrmaskin.

När du har konfigurerat Redis-servern måste du installera Python-bindningar för Redis. [redis-py](https://pypi.org/project/redis/) är den bindning som stöds naturligt av Django. Installation av paketet [hiredis-py](https://pypi.org/project/hiredis/) rekommenderas också.

För att använda Redis som cache-backend med Django:

- Ställ in [`BACKEND`](/sv/6.0/ref/settings/#std-setting-CACHES-BACKEND) till `django.core.cache.backends.redis.RedisCache`.
- Set [`LOCATION`](/sv/6.0/ref/settings/#std-setting-CACHES-LOCATION) to the URL pointing to your Redis
  instance, using the appropriate scheme. See the `redis-py` docs for
  [details on the available schemes](https://redis.readthedocs.io/en/stable/connections.html#redis.connection.ConnectionPool.from_url).

Till exempel, om Redis körs på localhost (127.0.0.1) port 6379:

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

Ofta är Redis-servrar skyddade med autentisering. För att ange ett användarnamn och lösenord, lägg till dem i `LOCATION` tillsammans med URL:

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

Om du har konfigurerat flera Redis-servrar i replikationsläget kan du ange servrarna antingen som en semikolon- eller kommaseparerad sträng eller som en lista. När du använder flera servrar utförs skrivoperationer på den första servern (leader). Läsoperationer utförs på de andra servrarna (replikerna) som väljs slumpmässigt:

```
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": [
            "redis://127.0.0.1:6379",  # leader
            "redis://127.0.0.1:6378",  # read-replica 1
            "redis://127.0.0.1:6377",  # read-replica 2
        ],
    }
}
```

### Cachelagring av databas

Django kan lagra sina cachade data i din databas. Detta fungerar bäst om du har en snabb, välindexerad databasserver.

För att använda en databastabell som cache-backend:

- Ställ in [`BACKEND`](/sv/6.0/ref/settings/#std-setting-CACHES-BACKEND) till `django.core.cache.backends.db.DatabaseCache`
- Ställ in [`LOCATION`](/sv/6.0/ref/settings/#std-setting-CACHES-LOCATION) till `tablename`, namnet på databastabellen. Detta namn kan vara vad du vill, så länge det är ett giltigt tabellnamn som inte redan används i din databas.

I det här exemplet är cachetabellens namn `my_cache_table`:

```
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.db.DatabaseCache",
        "LOCATION": "my_cache_table",
    }
}
```

Till skillnad från andra cache-backends har databascachen inte stöd för automatisk gallring av utgångna poster på databasnivå. Istället gallras utgångna cacheposter varje gång `add()`, `set()` eller `touch()` anropas.

#### Skapa cache-tabellen

Innan du använder databascachen måste du skapa cachetabellen med det här kommandot:

```shell
python manage.py createcachetable
```

Detta skapar en tabell i din databas som är i det korrekta format som Djangos databas-cache-system förväntar sig. Namnet på tabellen hämtas från [`LOCATION`](/sv/6.0/ref/settings/#std-setting-CACHES-LOCATION).

Om du använder flera databascacher skapar [`createcachetable`](/sv/6.0/ref/django-admin/#django-admin-createcachetable) en tabell för varje cache.

Om du använder flera databaser följer [`createcachetable`](/sv/6.0/ref/django-admin/#django-admin-createcachetable) metoden `allow_migrate()` i dina databasroutrar (se nedan).

Precis som [`migrate`](/sv/6.0/ref/django-admin/#django-admin-migrate) kommer [`createcachetable`](/sv/6.0/ref/django-admin/#django-admin-createcachetable) inte att röra en befintlig tabell. Den kommer bara att skapa tabeller som saknas.

Om du vill skriva ut den SQL som ska köras, i stället för att köra den, använder du alternativet [`createcachetable --dry-run`](/sv/6.0/ref/django-admin/#cmdoption-createcachetable-dry-run).

#### Flera databaser

Om du använder databascache med flera databaser måste du också ställa in routningsinstruktioner för din databascachetabell. När det gäller routing visas databasens cachetabell som en modell med namnet `CacheEntry`, i en applikation med namnet `django_cache`. Denna modell kommer inte att visas i modellcachen, men modellinformationen kan användas för routingändamål.

Följande router skulle till exempel styra alla läsoperationer i cachen till `cache_replica` och alla skrivoperationer till `cache_primary`. Cachetabellen kommer endast att synkroniseras till `cache_primary`:

```
class CacheRouter:
    """A router to control all database cache operations"""

    def db_for_read(self, model, **hints):
        "All cache read operations go to the replica"
        if model._meta.app_label == "django_cache":
            return "cache_replica"
        return None

    def db_for_write(self, model, **hints):
        "All cache write operations go to primary"
        if model._meta.app_label == "django_cache":
            return "cache_primary"
        return None

    def allow_migrate(self, db, app_label, model_name=None, **hints):
        "Only install the cache model on primary"
        if app_label == "django_cache":
            return db == "cache_primary"
        return None
```

Om du inte anger några routningsanvisningar för databasens cachemodell kommer cache-backend att använda standarddatabasen.

Och om du inte använder databascache-backend behöver du inte oroa dig för att tillhandahålla routningsinstruktioner för databascachemodellen.

### Cachelagring i filsystem

Den filbaserade backend serialiserar och lagrar varje cache-värde som en separat fil. För att använda denna backend, sätt [`BACKEND`](/sv/6.0/ref/settings/#std-setting-CACHES-BACKEND) till `"django.core.cache.backends.filebased.FileBasedCache"` och [`LOCATION`](/sv/6.0/ref/settings/#std-setting-CACHES-LOCATION) till en lämplig katalog. Till exempel, för att lagra cachad data i `/var/tmp/django_cache`, använd denna inställning:

```
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": "/var/tmp/django_cache",
    }
}
```

Om du använder Windows sätter du enhetsbeteckningen i början av sökvägen, så här:

```
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": "c:/foo/bar",
    }
}
```

Katalogsökvägen ska vara absolut, dvs. den ska börja vid roten av filsystemet. Det spelar ingen roll om du lägger till ett snedstreck i slutet av inställningen.

Se till att katalogen som den här inställningen pekar på antingen finns och är läsbar och skrivbar, eller att den kan skapas av systemanvändaren som din webbserver körs under. Om du fortsätter med exemplet ovan och din server körs som användaren `apache` måste du se till att katalogen `/var/tmp/django_cache` finns och är läsbar och skrivbar av användaren `apache`, eller att den kan skapas av användaren `apache`.

> **Warning**
>
> När cacheminnet [`LOCATION`](/sv/6.0/ref/settings/#std-setting-CACHES-LOCATION) ingår i [`MEDIA_ROOT`](/sv/6.0/ref/settings/#std-setting-MEDIA_ROOT), [`STATIC_ROOT`](/sv/6.0/ref/settings/#std-setting-STATIC_ROOT) eller [`STATICFILES_FINDERS`](/sv/6.0/ref/settings/#std-setting-STATICFILES_FINDERS) kan känsliga data exponeras.
>
> En angripare som får tillgång till cachefilen kan inte bara förfalska HTML-innehåll, som din webbplats kommer att lita på, utan också fjärrköra godtycklig kod, eftersom data serialiseras med [`pickle`](https://docs.python.org/3/library/pickle.html#module-pickle).

> **Warning**
>
> Filsystemets cachelagring kan bli långsam när ett stort antal filer lagras. Om du stöter på detta problem bör du överväga att använda en annan cachemekanism. Du kan också underklassa [FileBasedCache](https://github.com/django/django/blob/stable/6.0.x/django/core/cache/backends/filebased.py) och förbättra gallringsstrategin.

### Cachelagring i lokalt minne

Detta är standardcachen om ingen annan anges i din inställningsfil. Om du vill ha hastighetsfördelarna med cachning i minnet men inte har möjlighet att köra Memcached kan du överväga backend för cache i lokalt minne. Denna cache är per-process (se nedan) och trådsäker. För att använda den, ställ in [`BACKEND`](/sv/6.0/ref/settings/#std-setting-CACHES-BACKEND) till `"django.core.cache.backends.locmem.LocMemCache"`. Till exempel:

```
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.locmem.LocMemCache",
        "LOCATION": "unique-snowflake",
    }
}
```

Cacheminnet [`LOCATION`](/sv/6.0/ref/settings/#std-setting-CACHES-LOCATION) används för att identifiera enskilda minneslagringar. Om du bara har en `locmem`-cache kan du utelämna [`LOCATION`](/sv/6.0/ref/settings/#std-setting-CACHES-LOCATION); men om du har mer än en lokal minnescache måste du tilldela ett namn till minst en av dem för att hålla dem åtskilda.

Cachen använder en LRU-strategi (least-recently-used) för gallring.

Observera att varje process kommer att ha sin egen privata cache-instans, vilket innebär att ingen cachelagring över processgränserna är möjlig. Detta innebär också att den lokala minnescachen inte är särskilt minneseffektiv, så det är förmodligen inte ett bra val för produktionsmiljöer. Det är trevligt för utveckling.

### Dummy-cachelagring (för utveckling)

Slutligen levereras Django med en ”dummy”-cache som faktiskt inte cachelagrar - den implementerar bara cache-gränssnittet utan att göra någonting.

Detta är användbart om du har en produktionswebbplats som använder kraftig cachelagring på olika ställen men en utvecklings-/testmiljö där du inte vill cachelagra och inte vill behöva ändra din kod för att specialanpassa det senare. För att aktivera dummy-caching, ställ in [`BACKEND`](/sv/6.0/ref/settings/#std-setting-CACHES-BACKEND) så här:

```
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.dummy.DummyCache",
    }
}
```

### Använda en anpassad cache-backend

Även om Django inkluderar stöd för ett antal cache-backends direkt, kanske du ibland vill använda en anpassad cache-backend. För att använda en extern cache-backend med Django, använd Python-importsökvägen som [`BACKEND`](/sv/6.0/ref/settings/#std-setting-CACHES-BACKEND) i [`CACHES`](/sv/6.0/ref/settings/#std-setting-CACHES)-inställningen, så här:

```
CACHES = {
    "default": {
        "BACKEND": "path.to.backend",
    }
}
```

Om du bygger din egen backend kan du använda standardcache-backends som referensimplementeringar. Du hittar koden i katalogen [django/core/cache/backends/](https://github.com/django/django/blob/stable/6.0.x/django/core/cache/backends/) i Django-källan.

Obs: Utan en riktigt tvingande anledning, till exempel en värd som inte stöder dem, bör du hålla dig till de cache-backends som ingår i Django. De har testats väl och är väldokumenterade.

### Cache-argument

Varje cache-backend kan ges ytterligare argument för att styra cachningens beteende. Dessa argument anges som ytterligare nycklar i inställningen [`CACHES`](/sv/6.0/ref/settings/#std-setting-CACHES). Giltiga argument är följande:

- [`TIMEOUT`](/sv/6.0/ref/settings/#std-setting-CACHES-TIMEOUT): Standardtimeout i sekunder som ska användas för cacheminnet. Standardvärdet för detta argument är `300` sekunder (5 minuter). Du kan ställa in `TIMEOUT` till `None` så att cache-nycklarna som standard aldrig går ut. Ett värde på `0` gör att nycklar omedelbart upphör att gälla (i praktiken ”cachas inte”).
- [`OPTIONS`](/sv/6.0/ref/settings/#std-setting-CACHES-OPTIONS): Alla alternativ som ska skickas till cache-backend. Listan över giltiga alternativ varierar med varje backend, och cache-backends som backas upp av ett tredjepartsbibliotek skickar sina alternativ direkt till det underliggande cachebiblioteket.

  Cache-backends som implementerar sin egen gallringsstrategi (dvs. backends för `locmem`, `filsystem` och `databas`) kommer att respektera följande alternativ:

  - `MAX_ENTRIES`: Det maximala antalet poster som tillåts i cacheminnet innan gamla värden raderas. Standardvärdet för detta argument är `300`.
  - `CULL_FREQUENCY`: Den andel av posterna som gallras när `MAX_ENTRIES` har uppnåtts. Det faktiska förhållandet är `1 / CULL_FREQUENCY`, så sätt `CULL_FREQUENCY` till `2` för att gallra hälften av posterna när `MAX_ENTRIES` nås. Detta argument bör vara ett heltal och standardvärdet är `3`.

    Ett värde på `0` för `CULL_FREQUENCY` innebär att hela cachen kommer att dumpas när `MAX_ENTRIES` nås. På vissa backends (i synnerhet `databasen`) gör detta utrensningen *mycket* snabbare på bekostnad av fler cachemissar.

  Backends för Memcached och Redis skickar innehållet i [`OPTIONS`](/sv/6.0/ref/settings/#std-setting-CACHES-OPTIONS) som nyckelordsargument till klientkonstruktörerna, vilket möjliggör mer avancerad kontroll av klientbeteendet. För exempel på användning, se nedan.
- [`KEY_PREFIX`](/sv/6.0/ref/settings/#std-setting-CACHES-KEY_PREFIX): En sträng som automatiskt kommer att inkluderas (prepended som standard) till alla cache-nycklar som används av Django-servern.

  Se [cache-dokumentationen](#cache-key-prefixing) för mer information.
- [`VERSION`](/sv/6.0/ref/settings/#std-setting-CACHES-VERSION): Standardversionsnummer för cache-nycklar som genereras av Django-servern.

  Se [cache-dokumentationen](#cache-versioning) för mer information.
- [`KEY_FUNCTION`](/sv/6.0/ref/settings/#std-setting-CACHES-KEY_FUNCTION) En sträng som innehåller en prickad sökväg till en funktion som definierar hur ett prefix, en version och en nyckel ska sättas samman till en slutlig cache-nyckel.

  Se [cache-dokumentationen](#cache-key-transformation) för mer information.

I det här exemplet konfigureras en backend för ett filsystem med en timeout på 60 sekunder och en maximal kapacitet på 1000 objekt:

```
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",
        "LOCATION": "/var/tmp/django_cache",
        "TIMEOUT": 60,
        "OPTIONS": {"MAX_ENTRIES": 1000},
    }
}
```

Här följer ett exempel på konfiguration för en `pylibmc`-baserad backend som aktiverar det binära protokollet, SASL-autentisering och beteendeläget `ketama`:

```
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.memcached.PyLibMCCache",
        "LOCATION": "127.0.0.1:11211",
        "OPTIONS": {
            "binary": True,
            "username": "user",
            "password": "pass",
            "behaviors": {
                "ketama": True,
            },
        },
    }
}
```

Här är ett exempel på konfiguration för en `pymemcache`-baserad backend som aktiverar klientpoolning (vilket kan förbättra prestanda genom att hålla klienter anslutna), behandlar memcache/nätverksfel som cachemissar och ställer in flaggan `TCP_NODELAY` på anslutningens socket:

```
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",
        "LOCATION": "127.0.0.1:11211",
        "OPTIONS": {
            "no_delay": True,
            "ignore_exc": True,
            "max_pool_size": 4,
            "use_pooling": True,
        },
    }
}
```

Här är ett exempel på konfiguration för en `redis`-baserad backend som väljer databas `10` (som standard levereras Redis med 16 logiska databaser) och anger en anpassad [connection pool class](https://github.com/redis/redis-py#connection-pools) (`redis.ConnectionPool` används som standard):

```
CACHES = {
    "default": {
        "BACKEND": "django.core.cache.backends.redis.RedisCache",
        "LOCATION": "redis://127.0.0.1:6379",
        "OPTIONS": {
            "db": "10",
            "pool_class": "redis.BlockingConnectionPool",
        },
    }
}
```

## Cache för varje webbplats

När cachen är konfigurerad är det enklaste sättet att använda cachelagring att cachelagra hela din webbplats. Du måste lägga till `'django.middleware.cache.UpdateCacheMiddleware'` och `'django.middleware.cache.FetchFromCacheMiddleware'` till din [`MIDDLEWARE`](/sv/6.0/ref/settings/#std-setting-MIDDLEWARE)-inställning, som i det här exemplet:

```
MIDDLEWARE = [
    "django.middleware.cache.UpdateCacheMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.middleware.cache.FetchFromCacheMiddleware",
]
```

> **Note**
>
> Nej, det är inte ett skrivfel: ”update”-medievaran måste vara först i listan och ”fetch”-medievaran måste vara sist. Detaljerna är lite otydliga, men se [Order of MIDDLEWARE](#order-of-middleware) nedan om du vill ha hela historien.

Lägg sedan till följande nödvändiga inställningar i din Django-inställningsfil:

- [`CACHE_MIDDLEWARE_ALIAS`](/sv/6.0/ref/settings/#std-setting-CACHE_MIDDLEWARE_ALIAS) – Det cache-alias som ska användas för lagring.
- [`CACHE_MIDDLEWARE_SECONDS`](/sv/6.0/ref/settings/#std-setting-CACHE_MIDDLEWARE_SECONDS) – Heltal antal sekunder som varje sida ska cachas.
- [`CACHE_MIDDLEWARE_KEY_PREFIX`](/sv/6.0/ref/settings/#std-setting-CACHE_MIDDLEWARE_KEY_PREFIX) – Om cacheminnet delas mellan flera webbplatser som använder samma Django-installation, sätt detta till namnet på webbplatsen eller någon annan sträng som är unik för denna Django-instans, för att förhindra nyckelkollisioner. Använd en tom sträng om du inte bryr dig.

`FetchFromCacheMiddleware` cachelagrar GET- och HEAD-svar med status 200, där begäran och svarshuvudena tillåter det. Svar på förfrågningar om samma URL med olika frågeparametrar betraktas som unika sidor och cachelagras separat. Detta middleware förväntar sig att en HEAD-begäran besvaras med samma svarsrubriker som motsvarande GET-begäran; i så fall kan det returnera ett cachelagrat GET-svar för HEAD-begäran.

Dessutom ställer `UpdateCacheMiddleware` automatiskt in några rubriker i varje `` HttpResponse` `` som påverkar [downstream cacher](#downstream-caches):

- Ställer in rubriken `Expires` till aktuellt datum/tid plus den definierade [`CACHE_MIDDLEWARE_SECONDS`](/sv/6.0/ref/settings/#std-setting-CACHE_MIDDLEWARE_SECONDS).
- Ställer in `Cache-Control`-rubriken för att ge en maxålder för sidan – återigen från [`CACHE_MIDDLEWARE_SECONDS`](/sv/6.0/ref/settings/#std-setting-CACHE_MIDDLEWARE_SECONDS)-inställningen.

Se [Middleware](/sv/6.0/topics/http/middleware/) för mer information om middleware.

Om en vy ställer in sin egen utgångstid för cachen (dvs. den har en `max-age`-sektion i sin `Cache-Control`-rubrik) kommer sidan att cachelagras fram till utgångstiden, i stället för att [`CACHE_MIDDLEWARE_SECONDS`](/sv/6.0/ref/settings/#std-setting-CACHE_MIDDLEWARE_SECONDS). Med hjälp av dekoratorerna i `django.views.decorators.cache` kan du enkelt ställa in en vys utgångstid (med hjälp av dekoratorn [`cache_control()`](/sv/6.0/topics/http/decorators/#django.views.decorators.cache.cache_control)) eller inaktivera cachning för en vy (med hjälp av dekoratorn [`never_cache()`](/sv/6.0/topics/http/decorators/#django.views.decorators.cache.never_cache)). Se avsnittet [Använda andra rubriker](#controlling-cache-using-other-headers) för mer information om dessa dekoratorer.

Om [`USE_I18N`](/sv/6.0/ref/settings/#std-setting-USE_I18N) är inställd på `True` kommer den genererade cache-nyckeln att innehålla namnet på den aktiva [language](/sv/6.0/topics/i18n/#term-language-code) – se även [Hur Django upptäcker språkpreferenser](/sv/6.0/topics/i18n/translation/#how-django-discovers-language-preference)). Detta gör att du enkelt kan cachelagra flerspråkiga webbplatser utan att behöva skapa cache-nyckeln själv.

Cache-nycklar inkluderar även [aktuell tidszon](/sv/6.0/topics/i18n/timezones/#default-current-time-zone) när [`USE_TZ`](/sv/6.0/ref/settings/#std-setting-USE_TZ) är satt till `True`.

## Cache för varje visning

#### `django.views.decorators.cache.cache_page(timeout, * (Keyword-only parameters separator (PEP 3102)), cache=None, key_prefix=None)`

Ett mer detaljerat sätt att använda cachelagringsramverket är genom att cachelagra utdata från enskilda vyer. `django.views.decorators.cache` definierar en `cache_page` dekorator som automatiskt kommer att cacha vyns svar åt dig:

```
from django.views.decorators.cache import cache_page

@cache_page(60 * 15)
def my_view(request): ...
```

`cache_page` tar ett enda argument: cachens timeout, i sekunder. I exemplet ovan kommer resultatet av vyn `my_view()` att cachas i 15 minuter. (Observera att vi har skrivit det som `60 * 15` för läsbarhetens skull. `60 * 15` kommer att utvärderas till `900` \- det vill säga 15 minuter multiplicerat med 60 sekunder per minut)

Den timeout för cachen som ställs in av `cache_page` har företräde framför `max-age`-direktivet från `Cache-Control`-headern.

Cachen per vy är, precis som cachen per webbplats, kopplad till webbadressen. Om flera webbadresser pekar på samma vy kommer varje webbadress att cachas separat. Om vi fortsätter med exemplet `my_view`, om din URLconf ser ut så här:

```
urlpatterns = [
    path("foo/<int:code>/", my_view),
]
```

så kommer förfrågningar till `/foo/1/` och `/foo/23/` att cachelagras separat, som du kanske förväntar dig. Men när en viss URL (t.ex. `/foo/23/`) har begärts, kommer efterföljande begäranden till den URL:en att använda cacheminnet.

`cache_page` kan också ta ett valfritt nyckelordsargument, `cache`, som instruerar dekoratorn att använda en specifik cache (från din [`CACHES`](/sv/6.0/ref/settings/#std-setting-CACHES)-inställning) när du cachar vyresultat. Som standard kommer `default`-cachen att användas, men du kan ange vilken cache du vill:

```
@cache_page(60 * 15, cache="special_cache")
def my_view(request): ...
```

You can also override the cache prefix on a per-view basis. `cache_page`
takes an optional keyword argument, `key_prefix`,
which works in the same way as the [`CACHE_MIDDLEWARE_KEY_PREFIX`](/sv/6.0/ref/settings/#std-setting-CACHE_MIDDLEWARE_KEY_PREFIX)
setting for the middleware. It can be used like this:

```
@cache_page(60 * 15, key_prefix="site1")
def my_view(request): ...
```

Argumenten `key_prefix` och `cache` kan anges tillsammans. Argumentet `key_prefix` och [`KEY_PREFIX`](/sv/6.0/ref/settings/#std-setting-CACHES-KEY_PREFIX) som anges under [`CACHES`](/sv/6.0/ref/settings/#std-setting-CACHES) kommer att sammanfogas.

Dessutom ställer `cache_page` automatiskt in `Cache-Control` och `Expires` rubriker i svaret som påverkar [downstream caches](#downstream-caches).

> **Responses are cached before response middleware runs**
>
> `cache_page` is intended for content that is safe to reuse for requests
> to the same URL. It does not automatically vary by authentication,
> sessions, cookies, or other request-specific state.
>
> As a decorator wrapping the view directly, responses are cached before
> response middleware runs. If cache variation depends on response
> middleware, ensure it runs before the response is cached. For example, when
> caching views containing CSRF-protected forms, follow
> [Använda CSRF-skydd med cachelagring](/sv/6.0/howto/csrf/#csrf-cache-page) to ensure the `Vary` header is set first.

### Ange cache per vy i URLconf

The examples in the previous section have hardcoded the fact that the view is
cached, because `cache_page` alters the `my_view` function in place. This
approach couples your view to the cache system, which is not ideal for several
reasons. For instance, you might want to reuse the view functions on another,
cache-less site, or you might want to distribute the views to people who might
want to use them without being cached. The solution to these problems is to
specify the per-view cache in the URLconf rather than next to the view
functions themselves.

Du kan göra det genom att linda in vyfunktionen med `cache_page` när du hänvisar till den i URLconf. Här är den gamla URLconf från tidigare:

```
urlpatterns = [
    path("foo/<int:code>/", my_view),
]
```

Här är samma sak, med `my_view` inlindad i `cache_page`:

```
from django.views.decorators.cache import cache_page

urlpatterns = [
    path("foo/<int:code>/", cache_page(60 * 15)(my_view)),
]
```

## Cachelagring av mallfragment

Om du vill ha ännu mer kontroll kan du också cacha mallfragment med hjälp av malltaggen `cache`. För att ge din mall tillgång till denna tagg, lägg `{% load cache %}` nära toppen av din mall.

Malltaggen `{% cache %}` cachar innehållet i blocket under en viss tid. Den tar minst två argument: cache timeout, i sekunder, och det namn som ska ges till cachefragmentet. Fragmentet cachelagras för evigt om timeout är `None`. Namnet kommer att tas som det är, använd inte en variabel. Till exempel:

```html+django
{% load cache %}
{% cache 500 sidebar %}
    .. sidebar ..
{% endcache %}
```

Ibland kanske du vill cacha flera kopior av ett fragment beroende på dynamiska data som visas i fragmentet. Du kanske till exempel vill ha en separat cachad kopia av sidofältet som användes i föregående exempel för varje användare av din webbplats. Gör detta genom att skicka ett eller flera ytterligare argument, som kan vara variabler med eller utan filter, till malltaggen `{% cache %}` för att unikt identifiera cachefragmentet:

```html+django
{% load cache %}
{% cache 500 sidebar request.user.username %}
    .. sidebar for logged-in user ..
{% endcache %}
```

Om [`USE_I18N`](/sv/6.0/ref/settings/#std-setting-USE_I18N) är inställd på `True` kommer den webbplatsspecifika middleware-cachen att [respektera det aktiva språket](#i18n-cache-key). För malltaggen `cache` kan du använda en av de [översättningsspecifika variabler](/sv/6.0/topics/i18n/translation/#template-translation-vars) som finns i mallar för att uppnå samma resultat:

```html+django
{% load i18n %}
{% load cache %}

{% get_current_language as LANGUAGE_CODE %}

{% cache 600 welcome LANGUAGE_CODE %}
    {% translate "Welcome to example.com" %}
{% endcache %}
```

Cachens timeout kan vara en mallvariabel, så länge mallvariabeln motsvarar ett heltal. Om mallvariabeln `my_timeout` till exempel är inställd på värdet `600`, är följande två exempel likvärdiga:

```html+django
{% cache 600 sidebar %} ... {% endcache %}
{% cache my_timeout sidebar %} ... {% endcache %}
```

Den här funktionen är användbar för att undvika upprepningar i mallar. Du kan ställa in timeouten i en variabel på ett ställe och återanvända det värdet.

Som standard kommer cache-taggen att försöka använda den cache som heter ”template\_fragments”. Om ingen sådan cache finns kommer den att återgå till att använda standardcachen. Du kan välja en alternativ cache-backend att använda med nyckelordsargumentet `using`, som måste vara det sista argumentet till taggen.

```html+django
{% cache 300 local-thing ...  using="localcache" %}
```

Det betraktas som ett fel att ange ett cacheminnesnamn som inte är konfigurerat.

#### `django.core.cache.utils.make_template_fragment_key(fragment_name, vary_on=None)`

If you want to obtain the cache key used for a cached fragment, you can use
`make_template_fragment_key`. `fragment_name` is the same as the second
argument to the `cache` template tag; `vary_on` is a list of all additional
arguments passed to the tag. This function can be useful for invalidating or
overwriting a cached item, for example:

```pycon
>>> from django.core.cache import cache
>>> from django.core.cache.utils import make_template_fragment_key
# cache key for {% cache 500 sidebar username %}
>>> key = make_template_fragment_key("sidebar", [username])
>>> cache.delete(key)  # invalidates cached template fragment
True
```

## API för cache på låg nivå

Ibland tjänar man inte mycket på att cacha en hel renderad sida och det är i själva verket en obekväm överdrift.

Kanske innehåller din webbplats till exempel en vy vars resultat beror på flera dyra frågor, vars resultat ändras med olika intervall. I det här fallet skulle det inte vara idealiskt att använda den helsidescachelagring som cache-strategierna per webbplats eller per vy erbjuder, eftersom du inte skulle vilja cacha hela resultatet (eftersom vissa data ändras ofta), men du skulle fortfarande vilja cacha de resultat som sällan ändras.

For cases like this, Django exposes a low-level cache API. You can use this API
to store objects in the cache with any level of granularity you like. You can
cache any Python object that can be pickled safely: strings, dictionaries,
lists of model objects, and so forth. (Most common Python objects can be
pickled; refer to the [`Python documentation`](https://docs.python.org/3/library/pickle.html#module-pickle) for more information
about pickling.)

### Tillgång till cachen

#### `django.core.cache.caches`

Du kan komma åt de cacher som konfigurerats i inställningen [`CACHES`](/sv/6.0/ref/settings/#std-setting-CACHES) genom ett diktliknande objekt: `django.core.cache.caches`. Upprepade förfrågningar om samma alias i samma tråd kommer att returnera samma objekt.

```pycon
>>> from django.core.cache import caches
>>> cache1 = caches["myalias"]
>>> cache2 = caches["myalias"]
>>> cache1 is cache2
True
```

Om den angivna nyckeln inte finns kommer `InvalidCacheBackendError` att uppstå.

För att ge trådsäkerhet kommer en annan instans av cache-backend att returneras för varje tråd.

#### `django.core.cache.cache`

Som en genväg finns standardcachen tillgänglig som `django.core.cache.cache`:

```pycon
>>> from django.core.cache import cache
```

Detta objekt är likvärdigt med `caches['default']`.

### Grundläggande användning

Det grundläggande gränssnittet är:

#### `cache.set(key, value, timeout=DEFAULT_TIMEOUT, version=None)`

```pycon
>>> cache.set("my_key", "hello, world!", 30)
```

#### `cache.get(key, default=None, version=None)`

```pycon
>>> cache.get("my_key")
'hello, world!'
```

`key` bör vara en `str` och `value` kan vara vilket Python-objekt som helst.

Argumentet `timeout` är valfritt och standardvärdet är argumentet `timeout` för lämplig backend i inställningen [`CACHES`](/sv/6.0/ref/settings/#std-setting-CACHES) (förklaras ovan). Det är antalet sekunder som värdet ska lagras i cacheminnet. Om du anger `None` för `timeout` kommer värdet att cachas för alltid. En `timeout` på `0` kommer inte att cachelagra värdet.

Om objektet inte finns i cacheminnet returnerar `cache.get()` `None`:

```pycon
>>> # Wait 30 seconds for 'my_key' to expire...
>>> cache.get("my_key")
None
```

Om du behöver avgöra om objektet finns i cacheminnet och du har lagrat ett bokstavligt värde `None`, använd ett sentinel-objekt som standard:

```pycon
>>> sentinel = object()
>>> cache.get("my_key", sentinel) is sentinel
False
>>> # Wait 30 seconds for 'my_key' to expire...
>>> cache.get("my_key", sentinel) is sentinel
True
```

`cache.get()` kan ta ett `default` argument. Detta anger vilket värde som ska returneras om objektet inte finns i cacheminnet:

```pycon
>>> cache.get("my_key", "has expired")
'has expired'
```

#### `cache.add(key, value, timeout=DEFAULT_TIMEOUT, version=None)`

Om du vill lägga till en nyckel bara om den inte redan finns använder du metoden `add()`. Den tar samma parametrar som `set()`, men den kommer inte att försöka uppdatera cachen om den angivna nyckeln redan finns:

```pycon
>>> cache.set("add_key", "Initial value")
>>> cache.add("add_key", "New value")
>>> cache.get("add_key")
'Initial value'
```

Om du behöver veta om `add()` har lagrat ett värde i cacheminnet kan du kontrollera returvärdet. Det kommer att returnera `True` om värdet lagrades, `False` annars.

#### `cache.get_or_set(key, default, timeout=DEFAULT_TIMEOUT, version=None)`

Om du vill hämta en nyckels värde eller ange ett värde om nyckeln inte finns i cacheminnet finns metoden `get_or_set()`. Den tar samma parametrar som `get()` men standardvärdet sätts som det nya cachervärdet för den nyckeln, istället för att returneras:

```pycon
>>> cache.get("my_new_key")  # returns None
>>> cache.get_or_set("my_new_key", "my new value", 100)
'my new value'
```

Du kan också skicka vilken callable som helst som ett *standardvärde*:

```pycon
>>> import datetime
>>> cache.get_or_set("some-timestamp-key", datetime.datetime.now)
datetime.datetime(2014, 12, 11, 0, 15, 49, 457920)
```

#### `cache.get_many(keys, version=None)`

Det finns också ett `get_many()`-gränssnitt som bara träffar cacheminnet en gång. `get_many()` returnerar en ordbok med alla nycklar du bad om som faktiskt finns i cachen (och som inte har gått ut):

```pycon
>>> cache.set("a", 1)
>>> cache.set("b", 2)
>>> cache.set("c", 3)
>>> cache.get_many(["a", "b", "c"])
{'a': 1, 'b': 2, 'c': 3}
```

#### `cache.set_many(dict, timeout)`

Om du vill ange flera värden mer effektivt kan du använda `set_many()` för att skicka en ordbok med nyckel-värdepar:

```pycon
>>> cache.set_many({"a": 1, "b": 2, "c": 3})
>>> cache.get_many(["a", "b", "c"])
{'a': 1, 'b': 2, 'c': 3}
```

Liksom `cache.set()` har `set_many()` en valfri parameter `timeout`.

På backends som stöds (memcached) returnerar `set_many()` en lista över nycklar som inte kunde infogas.

#### `cache.delete(key, version=None)`

Du kan ta bort nycklar explicit med `delete()` för att rensa cacheminnet för ett visst objekt:

```pycon
>>> cache.delete("a")
True
```

`delete()` returnerar `True` om nyckeln har raderats framgångsrikt, `False` annars.

#### `cache.delete_many(keys, version=None)`

Om du vill rensa en massa nycklar på en gång kan `delete_many()` ta emot en lista med nycklar som ska rensas:

```pycon
>>> cache.delete_many(["a", "b", "c"])
```

#### `cache.clear()`

Finally, if you want to delete all the keys in the cache, use
`cache.clear()`. Be careful with this; `clear()` will remove *everything*
from the cache, not just the keys set by your application:

```pycon
>>> cache.clear()
```

#### `cache.touch(key, timeout=DEFAULT_TIMEOUT, version=None)`

`cache.touch()` anger en ny utgångsdatum för en nyckel. Till exempel, för att uppdatera en nyckel så att den upphör att gälla om 10 sekunder:

```pycon
>>> cache.touch("a", 10)
True
```

Precis som för andra metoder är argumentet `timeout` valfritt och standardvärdet är alternativet `TIMEOUT` för lämplig backend i inställningen [`CACHES`](/sv/6.0/ref/settings/#std-setting-CACHES).

`touch()` returnerar `True` om nyckeln berördes framgångsrikt, `False` annars.

#### `cache.incr(key, delta=1, version=None)`

#### `cache.decr(key, delta=1, version=None)`

Du kan också öka eller minska en nyckel som redan finns med hjälp av metoderna `incr()` respektive `decr()`. Som standard kommer det befintliga cache-värdet att ökas eller minskas med 1. Andra öknings-/dekrementeringsvärden kan anges genom att tillhandahålla ett argument till increment/decrement-anropet. Ett ValueError kommer att uppstå om du försöker öka eller minska en icke-existerande cache-nyckel:

```pycon
>>> cache.set("num", 1)
>>> cache.incr("num")
2
>>> cache.incr("num", 10)
12
>>> cache.decr("num")
11
>>> cache.decr("num", 5)
6
```

> **Note**
>
> metoderna `incr()`/decr()\` garanteras inte att vara atomiska. På de backends som stödjer atomär inkrementering/dekrementering (framför allt memcached-backend) kommer inkrementerings- och dekrementeringsoperationer att vara atomära. Men om backend inte naturligt tillhandahåller en inkrementerings-/dekrementeringsoperation kommer den att implementeras med hjälp av en tvåstegshämtning/uppdatering.

#### `cache.close()`

Du kan stänga anslutningen till din cache med `close()` om det implementeras av cache-backend.

```pycon
>>> cache.close()
```

> **Note**
>
> För cacher som inte implementerar `close`-metoder är det ett no-op.

> **Note**
>
> De asynkrona varianterna av basmetoderna har prefixet `a`, t.ex. `cache.aadd()` eller `cache.adelete_many()`. Se [Asynkront stöd](#id16) för mer information.

### Prefixering av nyckel i cacheminnet

Om du delar en cache-instans mellan olika servrar, eller mellan produktions- och utvecklingsmiljöerna, är det möjligt att data som har cachats av en server används av en annan server. Om formatet för cachade data skiljer sig åt mellan servrarna kan det leda till problem som är mycket svåra att diagnostisera.

För att förhindra detta ger Django möjlighet att prefixa alla cache-nycklar som används av en server. När en viss cache-nyckel sparas eller hämtas kommer Django automatiskt att prefixa cache-nyckeln med värdet av cache-inställningen [`KEY_PREFIX`](/sv/6.0/ref/settings/#std-setting-CACHES-KEY_PREFIX).

Genom att se till att varje Django-instans har en annan [`KEY_PREFIX`](/sv/6.0/ref/settings/#std-setting-CACHES-KEY_PREFIX) kan du se till att det inte blir några kollisioner i cache-värden.

### Versionering av cachen

När du ändrar körkod som använder cachade värden kan du behöva rensa bort eventuella befintliga cachade värden. Det enklaste sättet att göra detta är att rensa hela cacheminnet, men det kan leda till att cacheminnevärden som fortfarande är giltiga och användbara går förlorade.

Django tillhandahåller ett bättre sätt att rikta in sig på enskilda cache-värden. Djangos cache-ramverk har en systemomfattande versionsidentifierare, som anges med hjälp av cache-inställningen [`VERSION`](/sv/6.0/ref/settings/#std-setting-CACHES-VERSION). Värdet på denna inställning kombineras automatiskt med cacheprefixet och den användartillhandahållna cachekoden för att erhålla den slutliga cachekoden.

Som standard kommer alla nyckelbegäran automatiskt att inkludera webbplatsens standardversion av cache-nyckeln. De primitiva cachefunktionerna innehåller dock alla ett `version`-argument, så att du kan ange en viss cache-nyckelversion för att ställa in eller hämta. Till exempel:

```pycon
>>> # Set version 2 of a cache key
>>> cache.set("my_key", "hello world!", version=2)
>>> # Get the default version (assuming version=1)
>>> cache.get("my_key")
None
>>> # Get version 2 of the same key
>>> cache.get("my_key", version=2)
'hello world!'
```

Versionen av en specifik nyckel kan ökas och minskas med hjälp av metoderna `incr_version()` och `decr_version()`. Detta gör att specifika nycklar kan flyttas till en ny version, medan andra nycklar inte påverkas. Fortsättning på vårt tidigare exempel:

```pycon
>>> # Increment the version of 'my_key'
>>> cache.incr_version("my_key")
>>> # The default version still isn't available
>>> cache.get("my_key")
None
# Version 2 isn't available, either
>>> cache.get("my_key", version=2)
None
>>> # But version 3 *is* available
>>> cache.get("my_key", version=3)
'hello world!'
```

### Transformation av cache-nyckel

Som beskrivs i de två föregående avsnitten används inte den cachekod som en användare anger ordagrant, utan den kombineras med cacheprefixet och nyckelversionen för att ge en slutlig cachekod. Som standard sammanfogas de tre delarna med hjälp av kolon för att skapa en slutlig sträng:

```
def make_key(key, key_prefix, version):
    return "%s:%s:%s" % (key_prefix, version, key)
```

Om du vill kombinera delarna på olika sätt eller tillämpa annan bearbetning på den slutliga nyckeln (t.ex. ta en hashdigest av nyckeldelarna) kan du tillhandahålla en anpassad nyckelfunktion.

Cacheinställningen [`KEY_FUNCTION`](/sv/6.0/ref/settings/#std-setting-CACHES-KEY_FUNCTION) anger en prickad sökväg till en funktion som motsvarar prototypen för `make_key()` ovan. Om den anges kommer denna anpassade nyckelfunktion att användas i stället för standardfunktionen för nyckelkombination.

### Varningar för cache-nycklar

Memcached, den mest använda produktionscache-backend, tillåter inte cache-nycklar som är längre än 250 tecken eller innehåller blanksteg eller kontrolltecken, och användning av sådana nycklar kommer att orsaka ett undantag. För att uppmuntra cache-portabel kod och minimera obehagliga överraskningar utfärdar de andra inbyggda cache-backends en varning (`django.core.cache.backends.base.CacheKeyWarning`) om en nyckel används som skulle orsaka ett fel på memcached.

Om du använder en produktionsbackend som kan acceptera ett bredare utbud av nycklar (en anpassad backend eller en av de inbyggda backend som inte är memcached) och vill använda detta bredare utbud utan varningar, kan du tysta `CacheKeyWarning` med den här koden i modulen `management` i en av dina [`INSTALLED_APPS`](/sv/6.0/ref/settings/#std-setting-INSTALLED_APPS):

```
import warnings

from django.core.cache import CacheKeyWarning

warnings.simplefilter("ignore", CacheKeyWarning)
```

Om du istället vill tillhandahålla anpassad logik för nyckelvalidering för en av de inbyggda backends kan du underklassa den, åsidosätta bara metoden `validate_key` och följa instruktionerna för [använda en anpassad cache-backend](#id9). Till exempel, för att göra detta för `locmem` backend, lägg den här koden i en modul:

```
from django.core.cache.backends.locmem import LocMemCache

class CustomLocMemCache(LocMemCache):
    def validate_key(self, key):
        """Custom validation, raising exceptions or warnings as needed."""
        ...
```

…och använd den prickade Python-sökvägen till den här klassen i [`BACKEND`](/sv/6.0/ref/settings/#std-setting-CACHES-BACKEND)-delen av din [`CACHES`](/sv/6.0/ref/settings/#std-setting-CACHES)-inställning.

## Asynkront stöd

Django har utvecklat stöd för asynkrona cache-backends, men har ännu inte stöd för asynkron cachelagring. Det kommer att komma i en framtida version.

`django.core.cache.backends.base.BaseCache` har asynkrona varianter av [alla basmetoder](#cache-basic-interface). Av konvention är de asynkrona versionerna av alla metoder prefixerade med `a`. Som standard är argumenten för båda varianterna desamma:

```pycon
>>> await cache.aset("num", 1)
>>> await cache.ahas_key("num")
True
```

## Cacher nedströms

Hittills har detta dokument fokuserat på cachelagring av dina *egna* data. Men en annan typ av cachelagring är också relevant för webbutveckling: cachelagring som utförs av ”downstream”-cacher. Det är system som cachar sidor för användare redan innan förfrågan når din webbplats.

Här är några exempel på downstream-cacher:

- När du använder HTTP kan din ISP (Internet Service Provider) cachelagra vissa sidor, så om du begärde en sida från `http://example.com/` skulle din ISP skicka sidan till dig utan att behöva gå direkt till example.com. Underhållarna av example.com har ingen kännedom om denna cachelagring; ISP:n sitter mellan example.com och din webbläsare och hanterar all cachelagring på ett transparent sätt. Sådan cachelagring är inte möjlig under HTTPS eftersom det skulle utgöra en man-in-the-middle-attack.
- Din Django-webbplats kan ligga bakom en *proxy-cache*, till exempel Squid Web Proxy Cache (<http://www.squid-cache.org/>), som cachelagrar sidor för prestanda. I det här fallet skulle varje begäran först hanteras av proxyn, och den skulle skickas till din applikation endast om det behövs.
- Även din webbläsare cachar sidor. Om en webbsida skickar ut lämpliga rubriker kommer din webbläsare att använda den lokala cachade kopian för efterföljande förfrågningar till den sidan, utan att ens kontakta webbsidan igen för att se om den har ändrats.

Cachelagring nedströms är en trevlig effektivitetshöjare, men det finns en fara med det: Innehållet på många webbsidor skiljer sig åt beroende på autentisering och en mängd andra variabler, och cachesystem som blint sparar sidor baserat enbart på webbadresser kan exponera felaktiga eller känsliga data för efterföljande besökare på dessa sidor.

For example, if you operate a web email system, then the contents of the
”inbox” page depend on which user is logged in. If an ISP blindly cached your
site, then the first user who logged in through that ISP would have their
user-specific inbox page cached for subsequent visitors to the site. That’s
not cool.

Lyckligtvis erbjuder HTTP en lösning på detta problem. Det finns ett antal HTTP-rubriker som instruerar nedströmscacher att variera innehållet i cacheminnet beroende på angivna variabler och som talar om för cachemekanismer att de inte ska cacha vissa sidor. Vi kommer att titta på några av dessa rubriker i de avsnitt som följer.

## Använda `Vary`-rubriker

Headern `Vary` definierar vilka förfrågningsheaders som en cachemekanism ska ta hänsyn till när den bygger upp sin cache-nyckel. Om t.ex. innehållet på en webbsida beror på användarens språkpreferens, sägs sidan ”variera på språk”

Som standard skapar Djangos cachesystem sina cache-nycklar med hjälp av den begärda fullständigt kvalificerade URL:en - t.ex. `"https://www.example.com/stories/2005/?order_by=author"`. Detta innebär att varje begäran till den webbadressen kommer att använda samma cachade version, oavsett skillnader i användaragenter som cookies eller språkpreferenser. Men om den här sidan producerar olika innehåll baserat på någon skillnad i förfrågningsrubrikerna - till exempel en cookie, ett språk eller en användaragent - måste du använda `Vary`-rubriken för att berätta för cachemekanismerna att sidans utdata beror på dessa saker.

För att göra detta i Django, använd den praktiska [`django.views.decorators.vary.vary_on_headers()`](/sv/6.0/topics/http/decorators/#django.views.decorators.vary.vary_on_headers) vydekorator, så här:

```
from django.views.decorators.vary import vary_on_headers

@vary_on_headers("User-Agent")
def my_view(request): ...
```

I det här fallet kommer en cachemekanism (t.ex. Djangos egen cachemellanvara) att cacha en separat version av sidan för varje unik användaragent.

Fördelen med att använda dekoratorn `vary_on_headers` i stället för att manuellt ställa in rubriken `Vary` (med något som `response.headers['Vary'] = 'user-agent'`) är att dekoratorn *lägger till* rubriken `Vary` (som kanske redan finns), i stället för att ställa in den från början och potentiellt åsidosätta något som redan fanns där.

Du kan skicka flera rubriker till `vary_on_headers()`:

```
@vary_on_headers("User-Agent", "Cookie")
def my_view(request): ...
```

Detta innebär att nedströmscacher varierar på *båda*, vilket innebär att varje kombination av user-agent och cookie får sitt eget cachervärde. Till exempel kommer en begäran med user-agent `Mozilla` och cookie-värdet `foo=bar` att betraktas annorlunda än en begäran med user-agent `Mozilla` och cookie-värdet `foo=ham`.

Eftersom det är så vanligt att variera på cookie finns det en [`django.views.decorators.vary.vary_on_cookie()`](/sv/6.0/topics/http/decorators/#django.views.decorators.vary.vary_on_cookie) dekorator. Dessa två vyer är likvärdiga:

```
@vary_on_cookie
def my_view(request): ...

@vary_on_headers("Cookie")
def my_view(request): ...
```

De rubriker som du skickar till `vary_on_headers` är inte skiftlägeskänsliga; `"User-Agent"` är samma sak som `"user-agent"`.

Du kan också använda en hjälpfunktion, [`django.utils.cache.patch_vary_headers()`](/sv/6.0/ref/utils/#django.utils.cache.patch_vary_headers), direkt. Denna funktion ställer in, eller lägger till, `Vary header`. Till exempel:

```
from django.shortcuts import render
from django.utils.cache import patch_vary_headers

def my_view(request):
    ...
    response = render(request, "template_name", context)
    patch_vary_headers(response, ["Cookie"])
    return response
```

`patch_vary_headers` tar en [`HttpResponse`](/sv/6.0/ref/request-response/#django.http.HttpResponse)-instans som sitt första argument och en lista/tupel av skiftlägesokänsliga headernamn som sitt andra argument.

Mer information om Vary-rubriker finns i [**officiella Vary-specifikationer**](https://datatracker.ietf.org/doc/html/rfc9110.html#avsnitt-12.5.5).

> **CacheMiddleware varies on Authorization automatically**
>
> Although varying on `Authorization` is not strictly necessary given that
> [**RFC 9111 Section 3.5**](https://datatracker.ietf.org/doc/html/rfc9111.html#section-3.5) allows caches to avoid reusing authenticated
> responses, Django’s `CacheMiddleware` adds `Authorization` to the
> `Vary` header to simplify construction of cache keys.

> **Changed in Django 6.0.6**
>
> Previously, `UpdateCacheMiddleware` did not vary on `Authorization` for
> requests bearing that header.

## Kontroll av cache: Använda andra rubriker

Andra problem med cachelagring är integriteten för data och frågan om var data ska lagras i en kaskad av cacher.

En användare har vanligtvis två typer av cacheminnen: den egna webbläsarens cacheminne (ett privat cacheminne) och leverantörens cacheminne (ett publikt cacheminne). En publik cache används av flera användare och kontrolleras av någon annan. Detta innebär problem med känsliga data - du vill till exempel inte att ditt bankkontonummer ska lagras i en publik cache. Webbapplikationer behöver därför ett sätt att tala om för cacher vilka data som är privata och vilka som är offentliga.

Lösningen är att ange att en sidas cache ska vara ”privat” För att göra detta i Django, använd [`cache_control()`](/sv/6.0/topics/http/decorators/#django.views.decorators.cache.cache_control) vydekorator. Exempel:

```
from django.views.decorators.cache import cache_control

@cache_control(private=True)
def my_view(request): ...
```

Denna dekoratör tar hand om att skicka ut lämplig HTTP-header bakom kulisserna.

Observera att cachekontrollinställningarna ”private” och ”public” är ömsesidigt uteslutande. Dekoratorn säkerställer att ”public”-direktivet tas bort om ”private” ska ställas in (och vice versa). Ett exempel på användning av de två direktiven är en blogg som erbjuder både privata och offentliga inlägg. Offentliga poster kan cachelagras på vilken delad cache som helst. Följande kod använder [`patch_cache_control()`](/sv/6.0/ref/utils/#django.utils.cache.patch_cache_control), det manuella sättet att ändra cache-kontrollhuvudet (det kallas internt av [`cache_control()`](/sv/6.0/topics/http/decorators/#django.views.decorators.cache.cache_control)-dekoratorn):

```
from django.views.decorators.cache import patch_cache_control
from django.views.decorators.vary import vary_on_cookie

@vary_on_cookie
def list_blog_entries_view(request):
    if request.user.is_anonymous:
        response = render_only_public_entries()
        patch_cache_control(response, public=True)
    else:
        response = render_private_and_public_entries(request.user)
        patch_cache_control(response, private=True)

    return response
```

Du kan kontrollera nedströmscacher på andra sätt också (se [**RFC 9111**](https://datatracker.ietf.org/doc/html/rfc9111.html) för detaljer om HTTP-cachning). Till exempel, även om du inte använder Djangos cache-ramverk på serversidan, kan du fortfarande berätta för klienter att cacha en vy under en viss tid med [**max-age**](https://datatracker.ietf.org/doc/html/rfc9111.html#section-5.2.2.1)-direktivet:

```
from django.views.decorators.cache import cache_control

@cache_control(max_age=3600)
def my_view(request): ...
```

(Om du *använd* mellanvaran för cachelagring ställer den redan in `max-age` med värdet för inställningen [`CACHE_MIDDLEWARE_SECONDS`](/sv/6.0/ref/settings/#std-setting-CACHE_MIDDLEWARE_SECONDS). I så fall kommer den anpassade `max_age` från [`cache_control()`](/sv/6.0/topics/http/decorators/#django.views.decorators.cache.cache_control)-dekoratorn att ha företräde, och rubrikvärdena kommer att slås samman korrekt)

Alla giltiga svarsdirektiv för `Cache-Control` är giltiga i `cache_control()`. Här är några fler exempel:

- `no_transform=True`
- `must_revalidate=True`
- `stale_while_revalidate=num_seconds`
- `no_cache=True`

Den fullständiga listan över kända direktiv finns i ”IANA registry” (observera att inte alla direktiv gäller för svar).

Om du vill använda rubriker för att inaktivera cachning helt och hållet är [`never_cache()`](/sv/6.0/topics/http/decorators/#django.views.decorators.cache.never_cache) en vydekorator som lägger till rubriker för att säkerställa att svaret inte kommer att cachas av webbläsare eller andra cachar. Exempel:

```
from django.views.decorators.cache import never_cache

@never_cache
def myview(request): ...
```

## Beställning av `MIDDLEWARE`

Om du använder mellanprogram för cache är det viktigt att du placerar varje halva på rätt plats i [`MIDDLEWARE`](/sv/6.0/ref/settings/#std-setting-MIDDLEWARE)-inställningen. Det beror på att cachemellanvaran måste veta vilka rubriker som ska användas för att variera cachelagringen. Middleware lägger alltid till något i svarshuvudet `Vary` när det kan.

`UpdateCacheMiddleware` körs under svarsfasen, där middleware körs i omvänd ordning, så ett objekt högst upp i listan körs *sist* under svarsfasen. Därför måste du se till att `UpdateCacheMiddleware` visas *före* alla andra mellanprogram som kan lägga till något i `Vary`-headern. Följande middleware-moduler gör detta:

- `SessionMiddleware` lägger till `Cookie`
- `GZipMiddleware` lägger till `Accept-Encoding`
- `LocaleMiddleware` lägger till `Accept-Language`

`FetchFromCacheMiddleware` körs å andra sidan under request-fasen, där middleware tillämpas först till sist, så ett objekt högst upp i listan körs *först* under request-fasen. `FetchFromCacheMiddleware` måste också köras efter att annan middleware uppdaterar `Vary`-huvudet, så `FetchFromCacheMiddleware` måste vara *efter* alla objekt som gör det.