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.
\nFor most web applications, this overhead isn’t a big deal. Most web\napplications aren’t washingtonpost.com or slashdot.org; they’re\nsmall-to medium-sized sites with so-so traffic. But for medium- to high-traffic\nsites, it’s essential to cut as much overhead as possible.
Det är där cachelagring kommer in i bilden.
\nAtt 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:
\ngiven a URL, try finding that page in the cache\nif the page is in the cache:\n return the cached page\nelse:\n generate the page\n save the generated page in the cache (for next time)\n return the generated page\nDjango 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.
\nDjango fungerar också bra med ”nedströms” cacher, till exempel Squid 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.
\n\nCachesystemet 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.
\nDina cachepreferenser anges i inställningen CACHES i din inställningsfil. Här följer en förklaring av alla tillgängliga värden för CACHES.
Memcached ä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.
\nMemcached 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.
\nEfter 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 och pymemcache.
\nAtt använda Memcached med Django:
\nStäll in 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 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 = {\n "default": {\n "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",\n "LOCATION": "127.0.0.1:11211",\n }\n}\nI det här exemplet är Memcached tillgängligt via en lokal Unix-socketfil /tmp/memcached.sock med bindningen pymemcache:
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",\n "LOCATION": "unix:/tmp/memcached.sock",\n }\n}\nEn 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, 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:
\nCACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",\n "LOCATION": [\n "172.19.26.240:11211",\n "172.19.26.242:11211",\n ],\n }\n}\nI 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):
\nCACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",\n "LOCATION": [\n "172.19.26.240:11211",\n "172.19.26.242:11212",\n "172.19.26.244:11213",\n ],\n }\n}\nSom standard ställer backend PyMemcacheCache in följande alternativ (du kan åsidosätta dem i din OPTIONS):
"OPTIONS": {\n "allow_unicode_keys": True,\n "default_noreply": False,\n "serde": pymemcache.serde.pickle_serde,\n}\nEn 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.
\nRedis ä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.
\nNär du har konfigurerat Redis-servern måste du installera Python-bindningar för Redis. redis-py är den bindning som stöds naturligt av Django. Installation av paketet hiredis-py rekommenderas också.
\nFör att använda Redis som cache-backend med Django:
\nStäll in BACKEND till django.core.cache.backends.redis.RedisCache.
Set LOCATION to the URL pointing to your Redis\ninstance, using the appropriate scheme. See the redis-py docs for\ndetails on the available schemes.
Till exempel, om Redis körs på localhost (127.0.0.1) port 6379:
\nCACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.redis.RedisCache",\n "LOCATION": "redis://127.0.0.1:6379",\n }\n}\nOfta ä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 = {\n "default": {\n "BACKEND": "django.core.cache.backends.redis.RedisCache",\n "LOCATION": "redis://username:password@127.0.0.1:6379",\n }\n}\nOm 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:
\nCACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.redis.RedisCache",\n "LOCATION": [\n "redis://127.0.0.1:6379", # leader\n "redis://127.0.0.1:6378", # read-replica 1\n "redis://127.0.0.1:6377", # read-replica 2\n ],\n }\n}\nDjango kan lagra sina cachade data i din databas. Detta fungerar bäst om du har en snabb, välindexerad databasserver.
\nFör att använda en databastabell som cache-backend:
\nStäll in BACKEND till django.core.cache.backends.db.DatabaseCache
Ställ in 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 = {\n "default": {\n "BACKEND": "django.core.cache.backends.db.DatabaseCache",\n "LOCATION": "my_cache_table",\n }\n}\nUnlike other cache backends, the database cache does not support automatic\nculling of expired entries at the database level. Instead, an expired cache\nentry is deleted when evaluated by a get() request. Furthermore,\nexpired cache entries are culled when add(), set(), or touch()\nis called and the number of entries exceeds MAX_ENTRIES.
Innan du använder databascachen måste du skapa cachetabellen med det här kommandot:
\npython manage.py createcachetable\nDetta 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.
Om du använder flera databascacher skapar createcachetable en tabell för varje cache.
Om du använder flera databaser följer createcachetable metoden allow_migrate() i dina databasroutrar (se nedan).
Precis som migrate kommer 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.
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:\n """A router to control all database cache operations"""\n\n def db_for_read(self, model, **hints):\n "All cache read operations go to the replica"\n if model._meta.app_label == "django_cache":\n return "cache_replica"\n return None\n\n def db_for_write(self, model, **hints):\n "All cache write operations go to primary"\n if model._meta.app_label == "django_cache":\n return "cache_primary"\n return None\n\n def allow_migrate(self, db, app_label, model_name=None, **hints):\n "Only install the cache model on primary"\n if app_label == "django_cache":\n return db == "cache_primary"\n return None\nOm du inte anger några routningsanvisningar för databasens cachemodell kommer cache-backend att använda standarddatabasen.
\nOch om du inte använder databascache-backend behöver du inte oroa dig för att tillhandahålla routningsinstruktioner för databascachemodellen.
\nDen filbaserade backend serialiserar och lagrar varje cache-värde som en separat fil. För att använda denna backend, sätt BACKEND till "django.core.cache.backends.filebased.FileBasedCache" och 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 = {\n "default": {\n "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",\n "LOCATION": "/var/tmp/django_cache",\n }\n}\nOm du använder Windows sätter du enhetsbeteckningen i början av sökvägen, så här:
\nCACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",\n "LOCATION": "c:/foo/bar",\n }\n}\nKatalogsö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.
\nSe 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.
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 till "django.core.cache.backends.locmem.LocMemCache". Till exempel:
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.locmem.LocMemCache",\n "LOCATION": "unique-snowflake",\n }\n}\nCacheminnet LOCATION används för att identifiera enskilda minneslagringar. Om du bara har en locmem-cache kan du utelämna 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.
\nObservera 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.
\nSlutligen levereras Django med en ”dummy”-cache som faktiskt inte cachelagrar - den implementerar bara cache-gränssnittet utan att göra någonting.
\nDetta ä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 så här:
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.dummy.DummyCache",\n }\n}\nÄ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 i CACHES-inställningen, så här:
CACHES = {\n "default": {\n "BACKEND": "path.to.backend",\n }\n}\nOm du bygger din egen backend kan du använda standardcache-backends som referensimplementeringar. Du hittar koden i katalogen django/core/cache/backends/ i Django-källan.
\nObs: 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.
\nVarje cache-backend kan ges ytterligare argument för att styra cachningens beteende. Dessa argument anges som ytterligare nycklar i inställningen CACHES. Giltiga argument är följande:
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: 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 som nyckelordsargument till klientkonstruktörerna, vilket möjliggör mer avancerad kontroll av klientbeteendet. För exempel på användning, se nedan.
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 för mer information.
\nVERSION: Standardversionsnummer för cache-nycklar som genereras av Django-servern.
Se cache-dokumentationen för mer information.
\nKEY_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 för mer information.
\nI det här exemplet konfigureras en backend för ett filsystem med en timeout på 60 sekunder och en maximal kapacitet på 1000 objekt:
\nCACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",\n "LOCATION": "/var/tmp/django_cache",\n "TIMEOUT": 60,\n "OPTIONS": {"MAX_ENTRIES": 1000},\n }\n}\nHä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 = {\n "default": {\n "BACKEND": "django.core.cache.backends.memcached.PyLibMCCache",\n "LOCATION": "127.0.0.1:11211",\n "OPTIONS": {\n "binary": True,\n "username": "user",\n "password": "pass",\n "behaviors": {\n "ketama": True,\n },\n },\n }\n}\nHä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 = {\n "default": {\n "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",\n "LOCATION": "127.0.0.1:11211",\n "OPTIONS": {\n "no_delay": True,\n "ignore_exc": True,\n "max_pool_size": 4,\n "use_pooling": True,\n },\n }\n}\nHä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 (redis.ConnectionPool används som standard):
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.redis.RedisCache",\n "LOCATION": "redis://127.0.0.1:6379",\n "OPTIONS": {\n "db": "10",\n "pool_class": "redis.BlockingConnectionPool",\n },\n }\n}\nNä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-inställning, som i det här exemplet:
MIDDLEWARE = [\n "django.middleware.cache.UpdateCacheMiddleware",\n "django.middleware.common.CommonMiddleware",\n "django.middleware.cache.FetchFromCacheMiddleware",\n]\nLägg sedan till följande nödvändiga inställningar i din Django-inställningsfil:
\nCACHE_MIDDLEWARE_ALIAS – Det cache-alias som ska användas för lagring.
CACHE_MIDDLEWARE_SECONDS – Heltal antal sekunder som varje sida ska cachas.
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:
Ställer in rubriken Expires till aktuellt datum/tid plus den definierade 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-inställningen.
Se Middleware för mer information om middleware.
\nOm 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. 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()) eller inaktivera cachning för en vy (med hjälp av dekoratorn never_cache()). Se avsnittet Använda andra rubriker för mer information om dessa dekoratorer.
If USE_I18N is set to True then the generated cache key will\ninclude the name of the active language (see also\nHur Django upptäcker språkpreferenser). This allows you to easily\ncache multilingual sites without having to create the cache key yourself.
Cache-nycklar inkluderar även aktuell tidszon när USE_TZ är satt till True.
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\n\n\n@cache_page(60 * 15)\ndef my_view(request): ...\ncache_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 = [\n path("foo/<int:code>/", my_view),\n]\nså 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-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")\ndef my_view(request): ...\nYou can also override the cache prefix on a per-view basis. cache_page\ntakes an optional keyword argument, key_prefix,\nwhich works in the same way as the CACHE_MIDDLEWARE_KEY_PREFIX\nsetting for the middleware. It can be used like this:
@cache_page(60 * 15, key_prefix="site1")\ndef my_view(request): ...\nArgumenten key_prefix och cache kan anges tillsammans. Argumentet key_prefix och KEY_PREFIX som anges under CACHES kommer att sammanfogas.
Dessutom ställer cache_page automatiskt in Cache-Control och Expires rubriker i svaret som påverkar downstream caches.
The examples in the previous section have hardcoded the fact that the view is\ncached, because cache_page alters the my_view function in place. This\napproach couples your view to the cache system, which is not ideal for several\nreasons. For instance, you might want to reuse the view functions on another,\ncache-less site, or you might want to distribute the views to people who might\nwant to use them without being cached. The solution to these problems is to\nspecify the per-view cache in the URLconf rather than next to the view\nfunctions 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 = [\n path("foo/<int:code>/", my_view),\n]\nHär är samma sak, med my_view inlindad i cache_page:
from django.views.decorators.cache import cache_page\n\nurlpatterns = [\n path("foo/<int:code>/", cache_page(60 * 15)(my_view)),\n]\nOm 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:
{% load cache %}\n{% cache 500 sidebar %}\n .. sidebar ..\n{% endcache %}\nSometimes you might want to cache multiple copies of a fragment depending on\nsome dynamic data that appears inside the fragment. For example, you might want\na separate cached copy of the sidebar used in the previous example for every\nuser of your site. Do this by passing one or more additional arguments, which\nmay be variables with or without filters, to the {% cache %} template tag\nthat will uniquely identify the cache fragment when those values are converted\nto strings:
{% load cache %}\n{% cache 500 sidebar request.user.username %}\n .. sidebar for logged-in user ..\n{% endcache %}\nOm USE_I18N är inställd på True kommer den webbplatsspecifika middleware-cachen att respektera det aktiva språket. För malltaggen cache kan du använda en av de översättningsspecifika variabler som finns i mallar för att uppnå samma resultat:
{% load i18n %}\n{% load cache %}\n\n{% get_current_language as LANGUAGE_CODE %}\n\n{% cache 600 welcome LANGUAGE_CODE %}\n {% translate "Welcome to example.com" %}\n{% endcache %}\nCachens 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:
{% cache 600 sidebar %} ... {% endcache %}\n{% cache my_timeout sidebar %} ... {% endcache %}\nDen 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.
\nSom 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.
{% cache 300 local-thing ... using="localcache" %}\nDet betraktas som ett fel att ange ett cacheminnesnamn som inte är konfigurerat.
\nIf you want to obtain the cache key used for a cached fragment, you can use\nmake_template_fragment_key. fragment_name is the same as the second\nargument to the cache template tag; vary_on is a list of all additional\narguments passed to the tag. This function can be useful for invalidating or\noverwriting a cached item, for example:
>>> from django.core.cache import cache\n>>> from django.core.cache.utils import make_template_fragment_key\n# cache key for {% cache 500 sidebar username %}\n>>> key = make_template_fragment_key("sidebar", [username])\n>>> cache.delete(key) # invalidates cached template fragment\nTrue\nIbland tjänar man inte mycket på att cacha en hel renderad sida och det är i själva verket en obekväm överdrift.
\nKanske 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.
\nFor cases like this, Django exposes a low-level cache API. You can use this API\nto store objects in the cache with any level of granularity you like. You can\ncache any Python object that can be pickled safely: strings, dictionaries,\nlists of model objects, and so forth. (Most common Python objects can be\npickled; refer to the Python documentation for more information\nabout pickling.)
Du kan komma åt de cacher som konfigurerats i inställningen 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.
>>> from django.core.cache import caches\n>>> cache1 = caches["myalias"]\n>>> cache2 = caches["myalias"]\n>>> cache1 is cache2\nTrue\nOm 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.
\nSom en genväg finns standardcachen tillgänglig som django.core.cache.cache:
>>> from django.core.cache import cache\nDetta objekt är likvärdigt med caches['default'].
Det grundläggande gränssnittet är:
\n>>> cache.set("my_key", "hello, world!", 30)\n>>> cache.get("my_key")\n'hello, world!'\nkey 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 (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:
>>> # Wait 30 seconds for 'my_key' to expire...\n>>> cache.get("my_key")\nNone\nOm 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:
>>> sentinel = object()\n>>> cache.get("my_key", sentinel) is sentinel\nFalse\n>>> # Wait 30 seconds for 'my_key' to expire...\n>>> cache.get("my_key", sentinel) is sentinel\nTrue\ncache.get() kan ta ett default argument. Detta anger vilket värde som ska returneras om objektet inte finns i cacheminnet:
>>> cache.get("my_key", "has expired")\n'has expired'\nOm 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:
>>> cache.set("add_key", "Initial value")\n>>> cache.add("add_key", "New value")\n>>> cache.get("add_key")\n'Initial value'\nOm 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.
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:
>>> cache.get("my_new_key") # returns None\n>>> cache.get_or_set("my_new_key", "my new value", 100)\n'my new value'\nDu kan också skicka vilken callable som helst som ett standardvärde:
\n>>> import datetime\n>>> cache.get_or_set("some-timestamp-key", datetime.datetime.now)\ndatetime.datetime(2014, 12, 11, 0, 15, 49, 457920)\nDet 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):
>>> cache.set("a", 1)\n>>> cache.set("b", 2)\n>>> cache.set("c", 3)\n>>> cache.get_many(["a", "b", "c"])\n{'a': 1, 'b': 2, 'c': 3}\nOm du vill ange flera värden mer effektivt kan du använda set_many() för att skicka en ordbok med nyckel-värdepar:
>>> cache.set_many({"a": 1, "b": 2, "c": 3})\n>>> cache.get_many(["a", "b", "c"])\n{'a': 1, 'b': 2, 'c': 3}\nLiksom 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.
Du kan ta bort nycklar explicit med delete() för att rensa cacheminnet för ett visst objekt:
>>> cache.delete("a")\nTrue\ndelete() returnerar True om nyckeln har raderats framgångsrikt, False annars.
Om du vill rensa en massa nycklar på en gång kan delete_many() ta emot en lista med nycklar som ska rensas:
>>> cache.delete_many(["a", "b", "c"])\nFinally, if you want to delete all the keys in the cache, use\ncache.clear(). Be careful with this; clear() will remove everything\nfrom the cache, not just the keys set by your application:
>>> cache.clear()\ncache.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:
>>> cache.touch("a", 10)\nTrue\nPrecis som för andra metoder är argumentet timeout valfritt och standardvärdet är alternativet TIMEOUT för lämplig backend i inställningen CACHES.
touch() returnerar True om nyckeln berördes framgångsrikt, False annars.
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:
>>> cache.set("num", 1)\n>>> cache.incr("num")\n2\n>>> cache.incr("num", 10)\n12\n>>> cache.decr("num")\n11\n>>> cache.decr("num", 5)\n6\nDu kan stänga anslutningen till din cache med close() om det implementeras av cache-backend.
>>> cache.close()\nOm 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.
\nFö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.
Genom att se till att varje Django-instans har en annan KEY_PREFIX kan du se till att det inte blir några kollisioner i cache-värden.
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.
\nDjango 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. 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:
>>> # Set version 2 of a cache key\n>>> cache.set("my_key", "hello world!", version=2)\n>>> # Get the default version (assuming version=1)\n>>> cache.get("my_key")\nNone\n>>> # Get version 2 of the same key\n>>> cache.get("my_key", version=2)\n'hello world!'\nVersionen 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:
>>> # Increment the version of 'my_key'\n>>> cache.incr_version("my_key")\n>>> # The default version still isn't available\n>>> cache.get("my_key")\nNone\n# Version 2 isn't available, either\n>>> cache.get("my_key", version=2)\nNone\n>>> # But version 3 *is* available\n>>> cache.get("my_key", version=3)\n'hello world!'\nSom 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:
\ndef make_key(key, key_prefix, version):\n return "%s:%s:%s" % (key_prefix, version, key)\nOm 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.
\nCacheinställningen 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.
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:
import warnings\n\nfrom django.core.cache import CacheKeyWarning\n\nwarnings.simplefilter("ignore", CacheKeyWarning)\nOm 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. 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\n\n\nclass CustomLocMemCache(LocMemCache):\n def validate_key(self, key):\n """Custom validation, raising exceptions or warnings as needed."""\n ...\n…och använd den prickade Python-sökvägen till den här klassen i BACKEND-delen av din CACHES-inställning.
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.
\ndjango.core.cache.backends.base.BaseCache har asynkrona varianter av alla basmetoder. Av konvention är de asynkrona versionerna av alla metoder prefixerade med a. Som standard är argumenten för båda varianterna desamma:
>>> await cache.aset("num", 1)\n>>> await cache.ahas_key("num")\nTrue\nHittills 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.
\nHär är några exempel på downstream-cacher:
\nNär du använder HTTP kan din ISP 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.
\nFor example, if you operate a web email system, then the contents of the\n”inbox” page depend on which user is logged in. If an ISP blindly cached your\nsite, then the first user who logged in through that ISP would have their\nuser-specific inbox page cached for subsequent visitors to the site. That’s\nnot cool.
\nLyckligtvis 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.
\nVary-rubrikerLink to this heading#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() vydekorator, så här:
from django.views.decorators.vary import vary_on_headers\n\n\n@vary_on_headers("User-Agent")\ndef my_view(request): ...\nI 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.
\nFö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")\ndef my_view(request): ...\nDetta 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() dekorator. Dessa två vyer är likvärdiga:
@vary_on_cookie\ndef my_view(request): ...\n\n\n@vary_on_headers("Cookie")\ndef my_view(request): ...\nDe 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(), direkt. Denna funktion ställer in, eller lägger till, Vary header. Till exempel:
from django.shortcuts import render\nfrom django.utils.cache import patch_vary_headers\n\n\ndef my_view(request):\n ...\n response = render(request, "template_name", context)\n patch_vary_headers(response, ["Cookie"])\n return response\npatch_vary_headers tar en 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.
\n\n\nAndra problem med cachelagring är integriteten för data och frågan om var data ska lagras i en kaskad av cacher.
\nEn 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.
\nLösningen är att ange att en sidas cache ska vara ”privat” För att göra detta i Django, använd cache_control() vydekorator. Exempel:
from django.views.decorators.cache import cache_control\n\n\n@cache_control(private=True)\ndef my_view(request): ...\nDenna dekoratör tar hand om att skicka ut lämplig HTTP-header bakom kulisserna.
\nObservera 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(), det manuella sättet att ändra cache-kontrollhuvudet (det kallas internt av cache_control()-dekoratorn):
from django.views.decorators.cache import patch_cache_control\nfrom django.views.decorators.vary import vary_on_cookie\n\n\n@vary_on_cookie\ndef list_blog_entries_view(request):\n if request.user.is_anonymous:\n response = render_only_public_entries()\n patch_cache_control(response, public=True)\n else:\n response = render_private_and_public_entries(request.user)\n patch_cache_control(response, private=True)\n\n return response\nDu kan kontrollera nedströmscacher på andra sätt också (se RFC 9111 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-direktivet:
\nfrom django.views.decorators.cache import cache_control\n\n\n@cache_control(max_age=3600)\ndef my_view(request): ...\n(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. I så fall kommer den anpassade max_age från 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).
\nOm du vill använda rubriker för att inaktivera cachning helt och hållet är 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\n\n\n@never_cache\ndef myview(request): ...\nMIDDLEWARELink to this heading#Om du använder mellanprogram för cache är det viktigt att du placerar varje halva på rätt plats i 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.