Perjualan mendasar di situs jaringan dinamis adalah, baik, mereka adalah dinamis. Setiap kali seorang pengguna meminta sebuah halaman, peladen Jaringan membuat semua urutan perhitungan -- dari permintaan basisdata ke membangun cetakan ke logika bisnis -- untuk membuat halaman yang pengunjung situs anda lihat. Ini adalah sedikit mahal, dari pandangan pengolahan-atas, daripada pengaturan peladen baca-berkas-sitem-berkas standar anda.
\nFor most Web applications, this overhead isn't a big deal. Most Web\napplications aren't washingtonpost.com or slashdot.org; they're small-\nto medium-sized sites with so-so traffic. But for medium- to high-traffic\nsites, it's essential to cut as much overhead as possible.
Itu adalah dimana cache datang.
\nUntuk cache sesuatu adalah menyimpan hasil dari perhitungan mahal sehingga anda tidak harus melakukan perhitungan lain kali. Ini adalah beberapa kode semu menjelaskan bagaimana ini akan bekerja untuk secara dinamis membangkitkan halaman Jaringan:
\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 datang dengan sistem cache kuat yang membiarkan anda mentimpan halaman-halaman dinamis sehingga mereka tidak harus dihitung untuk setiap permintaan. Untuk kenyamanan, Django menawarkan tingkatan berbeda dari butiran cache: Anda dapat cache keluaran dari tampilan khusus, anda dapat cache hanya potongan-potongan yang sulit dihasilkan, atau anda dapat cache kelesuruhan situs anda.
\nDjango juga bekerja dengan cache "downstream", seperti Squid dan cache berdasarkan-peramban. Ini adalah jenis-jenis dari cache yang anda tidak secara langsung kendalikan tetapi yang anda dapat sediakan petunjuk-petunjuk (melalui kepala HTTP) tentang bagian-bagian mana dari situs anda harus di cache, dan bagaimana.
\n\nSistem cache membutuhkan sejumlah kecil pengaturan. Yaitu, anda harus memberitahu itu dimana data cache anda harus tinggal -- apakah di basisdata, pada sistem berkas atau langsung di memori. Ini adalah keputusan penting yang mempengaruhi penampilan cache anda; ya beberapa jenis cache adalah lebih cepat dari lainnya.
\nPilihan cache anda masuk di pengaturan CACHES di berkas pengaturan anda. Ini adalah sebuah penjelasan dari semua nilai-nilai tersedia untuk CACHES.
Tercepat, jenis paling efesien dari cache didukung alamiah oleh Django, Memcached adalah seluruhnya peladen cache berdasarkan-memori, aslinya dikembangkan untuk menangani pemuatan tinggi pada LiveJournal.com dan kemudian di sumber-terbukan oleh Danga Interactive. Itu digunakan oleh situs-situs seperti Facebook dan Wikipedia untuk mengurangi akses basisdata dan secara dramatis meningkatkan penampilan situs.
\nMemcached berjalan sebagai daemon dan memberikan sejumlah tertentu dari RAM. Semua itu lakukan adalah menyediakan antarmuka cepat untuk menambah, mengambil dan menghapus data di cache. Semua data disimpan secara langsung di memori, sehingga tidak ada kelebihan dari basisdata atau penggunaan sistem berkas.
\nSetelah memasang Memcached itu sendiri, anda akan butuh memasang ikatan Memcached. Ada beberapa ikatan Memcached Python tersedia; dua paling umum adalah python-memcached dan pylibmc.
\nUntuk menggunakan Memcache dengan Django:
\nSetel BACKEND menjadi django.core.cache.backends.memcached.MemcachedCache atau django.core.cache.backends.memcached.PyLibMCCache (tergantung pada pengikatan memcache anda pilih)
Setel LOCATION menjadi nilai-nilai ip:port, dimana ip adalah alamat IP dari daemon memcache dan port adalah pangkalan pada Memcache mana yang berjalan, atau menjadi nilai unix:path, dimana path adalah jalur ke berkas soket Unix Memcache.
Dalam contoh ini, Memcache berjalan pada localhost (127.0.0.1) pangkalan 11211, menggunakan pengikatan python-memcached:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n 'LOCATION': '127.0.0.1:11211',\n }\n}\nDalam contoh ini, Memcache tersedia melalui berkas soket Unix lokal /tmp/memcached.sock menggunakan pengikatan python-memcached:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n 'LOCATION': 'unix:/tmp/memcached.sock',\n }\n}\nKetika menggunakan mengikat pylibmc, jangan menyertakan awalan unix:/`
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',\n 'LOCATION': '/tmp/memcached.sock',\n }\n}\nSatu fitur yg hebar dari Memcache adalah kemampuannya berbagi sebuah cache terhadap banyak peladen. Ini berarti anda dapat menjalankan daemon Memcache pada banyak mesin, dan program akan memperlakukan kelompok mesin sebagai cache tunggal, tanpa butuh menggandakan nilai-nilai cache pada setiap mesin. Untuk mengambil keuntungan fitur ini, sertakan semua alamat peladen dalam LOCATION 1,antara sebagai titik koma atau string dipisahkan koma, atau sebagai sebuah daftar.
Di contoh ini, penyimpanan dibagi terhadao instance Memcache berjalan pada alamat IP 172.19.26.240 dan 172.19.26.242, keduanya di port 11211:
\nCACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n 'LOCATION': [\n '172.19.26.240:11211',\n '172.19.26.242:11211',\n ]\n }\n}\nDi contoh berikut, cache dibagi terhadap instance Memcache berjalan pada alamat IP 172.19.26.240 (port 11211), 172.19.26.242 (port 11212), dan 172.19.26.244 (port 11213):
\nCACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n 'LOCATION': [\n '172.19.26.240:11211',\n '172.19.26.242:11212',\n '172.19.26.244:11213',\n ]\n }\n}\nSebuah titik akhir tentang Memcached adalah cache berdasarkan-memori mempunyai kerugian: karena data cache disimpan di memori, data akan hilang jika peladen anda gagal. Jelasnya, memori tidak diperuntukkan untuk penyimpanan data tetap, jadi jangan bergantung oada cache berdasarkan-memori sebagai penyimpanan data anda satu-satunya -- mereka adalah diperuntukkan pemecahan untuk cache, bukan penyimpanan -- tetapi kami menitikkan ini disini karena cache berdasarkan-memori adalah khususnya sementara.
\nDjango dapat menyimpan data temboloknya dalam basisdata anda. Ini bekerja baik jika anda mendapatkan cepat, peladen basisdata diindeks baik.
\nUntuk menggunakan tabel basisdata sebagai backend tembolok anda:
\nSetel BACKEND menjadi django.core.cache.backends.db.DatabaseCache
Setel LOCATION menjadi tablename, nama dari tabel basisdata. Nama ini dapat menjadi apapun anda inginkan, selama dia adalah nama tabel yang sah yang tidak sedang digunakan dalam basisdata anda.
Dalam contoh ini, nama tabel tembolok adalah my_cache_table:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.db.DatabaseCache',\n 'LOCATION': 'my_cache_table',\n }\n}\nSebelum menggunakan basisdata tembolok, anda harus membuat tabel tembolok dengan perintah ini:
\npython manage.py createcachetable\nIni membuat tabel di basisdata anda yaitu dalam bentuk sesuai yang sistem tembolok-basidata harapkan. Nama dari tabel diambil dari LOCATION.
Jika anda menggunakan banyak basisdata tembolok, createcachetable membuat satu tabel untuk setiap tembolok.
Jika anda menggunakan banyak basisdata, createcachetable mengamati cara allow_migrate() dari perute basisdata anda (lihat dibawah).
Seperti migrate, createcachetable tidak akan menyentuh tabel yang ada. Dia tidak akan membuat tabel-tabel hilang.
Untuk mencetak SQL yang akan menjalankan, daripada menjalankannya, gunakan pilihan createcachetable --dry-run.
Jika anda menggunakan penembolokan basisdata dengan banyak basisdata, anda akan juga butuh menyetel perintah perutean untuk tabel tembolok basisdata anda. Untuk tujuan perutean, tabel tembolok basisdata muncul sebagai model dinamai CacheEntry, di aplikasi dinamai django_cache. Model ini tidak akan muncul dalam model tembolok, tetapi rincian model dapat digunakan untuk tujuan perutean.
Sebagai contoh, perute berikut akan melangsungkan semua tindakan pembacaan tembolok ke cache_replica, dan semua tindakan penulisan ke cache_primary. Tabel tembolok hanya disinkronisasikan kedalam 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\nJika anda tidak menentukan arah perute untuk model cache basisdata, backend cache akan menggunakan basisdata default.
And if you don't use the database cache backend, you don't need to worry about\nproviding routing instructions for the database cache model.
\nSerial backend berdasarkan-berkas dan menyimpan setiap nilai cache sebagai berkas terpisah. Untuk menggunakan backend ini setel BACKEND menjadi "django.core.cache.backends.filebased.FileBasedCache" dan LOCATION menjadi direktori yang cocok. Sebagai contoh, untuk menyimpan data di /var/tmp/django_cache, gunakan pengaturan ini:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',\n 'LOCATION': '/var/tmp/django_cache',\n }\n}\nJika anda berada di Windows, taruh huruf drive pada awal jalur, seperti ini:
\nCACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',\n 'LOCATION': 'c:/foo/bar',\n }\n}\nJalur direktori harus mutlak -- yaitu, itu harus dimulai pada induk dari sistem berkas anda. Itu tidak mengapa apakah anda menaruh sebuah garis miring pada akhir pengaturan.
\nMake sure the directory pointed-to by this setting either exists and is\nreadable and writable, or that it can be created by the system user under which\nyour Web server runs. Continuing the above example, if your server runs as the\nuser apache, make sure the directory /var/tmp/django_cache exists and\nis readable and writable by the user apache, or that it can be created by\nthe user apache.
Ini adalah cache awalan jika lainnya tidak ditentukan di berkas pengaturan anda. Jika anda ingin mempercepat keuntungan dari cace di-memori tetapi tidak mempunyai kemampuan dari menjalankan Memcached, perimbangkan backend cache memori-lokal. Cache ini adalah per-pengolahan (lihat dibawah) dan thread-safe. Untuk menggunakan itu, setel BACKEND menjadi "django.core.cache.backends.locmem.LocMemCache". Sebagai contoh:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',\n 'LOCATION': 'unique-snowflake',\n }\n}\nCache LOCATION digunakan untuk mencirikan penyimpanan memori tersendiri. Jika anda hanya mempunyai satu cache locmem, anda dapat mengabaikan LOCATION; bagaimanapun, jikla anda mempunyai lebih dari satu cache memori lokal, anda akan butuh memberikan sebuah nama pada setidaknya satu dari mereka agar menjaga mereka terpisah.
Penyimpanan sementara menggunakan strategi pemusnahan least-recently-used (LRU).
\nNote that each process will have its own private cache instance, which means no\ncross-process caching is possible. This also means the local memory cache isn't\nparticularly memory-efficient, so it's probably not a good choice for\nproduction environments. It's nice for development.
\nAkhirnya, Django datang dengan cache "dummy" yang tidak sebenarnya cache -- itu hanya menerapkan antarmuka cache tanpa melakukan apapun.
\nIni adalah sangat berguna jika anda mempunyai situs produksi yang menggunakan cache pekerjaan-berat di beragam tempat tetapi lingkungan pengembangan/percobaan dimana anda tidak ingin cache dan tidak ingin merubah kode anda pada kasus-khusus terakhir. Untuk mengaktifkan cache dummy, setel BACKEND seperti begitu:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.dummy.DummyCache',\n }\n}\nSelagi Django menyertakan dukungan untuk sejumlah backend cache keluar-dari-kotak, terkadang anda mungkin ingin menggunakan backend cache disesuaikan. Untuk menggunakan backend cache luar dengan Django, gunakan jalur impor Python sebagai BACKEND dari CACHES setting, seperti begitu:
CACHES = {\n 'default': {\n 'BACKEND': 'path.to.backend',\n }\n}\nJika anda sedang membangun backend anda sendiri, anda dapat menggunakan backend cache standar sebagai acuan penerapan. Anda akan menemukan kode di direktori django/core/cache/backends/ dari sumber Django.
Note: Without a really compelling reason, such as a host that doesn't support\nthem, you should stick to the cache backends included with Django. They've\nbeen well-tested and are well-documented.
\nSetiap backend cache dapat memberikan argumen tambahan untuk mengendalikan perilaku cache. Argumen-argumen ini disediakan sebagai kunci-kunci tambahan di pengaturan CACHES. Argumen-argumen sah seperti berikut:
TIMEOUT: Awalan waktu habis, dalam detik, untuk digunakan untuk cache. Awalan argumen ini pada 300 detik (5 menit). Anda dapat mensetel TIMEOUT menjadi None sehingga, secara awalan, kunci-kunci cache tidak pernah kadaluarsa. Sebuah nilai 0 menyebabkan kunci segera kadaluarsa (efektifnya "don't cache").
OPTIONS: Pilihan apapun yang harus dilewatkan ke backend cache. Daftar dari pilihan sah akan beragam dengan setiap backend, dan backend cache oleh pustaka pihak-ketiga akan melewatkan pilihan mereka langsung ke pustaka cache pokok.
Backend cache yang menerapkan strategi pemusnahan mereka sendiri (yaitu, backend locmem, filesystem dan database) akan menghormati pilihan-pilihan berikut:
MAX_ENTRIES: Nomor maksimal dari masukan diizinkan di cache sebelum nilai-nilai lama dihapus. Argumen ini awalan pada 300.
CULL_FREQUENCY`: Pecahan masukan yang dimusnahkan ketika MAX_ENTRIES dicapai. Rasio sebenarnya adalah 1 / CULL_FREQUENCY, jadi menyetel CULL_FREQUENCY menjadi 2 pada pemusnahan setengah masukan ketika MAX_ENTRIES``dicapai. Argumen ini harus berupa integer dan awalan pada ``3.
Sebuah nilai dari 0 untuk CULL_FREQUENCY berarti bahwa keseluruhan cache akan dibuang ketika MAX_ENTRIES dicapai. Pada beberapa backend (database khususnya) ini membuat pemusnahan jauh lebih cepat pada pengeluaran dari lebih cache luput.
Backend memcache melewatkan isi dari OPTIONS 1 sebagai argumen katakunci pada pembangun klien, mengizinkan untuk lebih lanjut mengendalikan perilaku klien. Sebagai contoh penggunaan, lihat dibawah.
KEY_PREFIX: Sebuah string yang akan otomatis disertakan (ditambahkan secara awalan) ke semua kunci-kunci cache digunakan oleh peladen Django.
Lihat cache documentation untuk informasi lebih.
\nVERSION: Nomor versi awalan untuk kunci-kunci cache dibangkitkan oleh peladen Django.
Lihat the cache documentation untuk informasi lebih.
\nKEY_FUNCTION Sebuah string mengandung jalur bertitik pada sebuah fungsi yang menentukan bagaimana menyusun sebuah awalan, versi dan kunci kedalam kunci cache akhir.
Lihat cache documentation untuk informasi lebih.
\nDi contoh ini, backend sistem berkas sedang dikonfigurasikan dengan waktu habis dari 60 detik, dan kapasitas maksimal dari 1000 barang:
\nCACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',\n 'LOCATION': '/var/tmp/django_cache',\n 'TIMEOUT': 60,\n 'OPTIONS': {\n 'MAX_ENTRIES': 1000\n }\n }\n}\nIni adalah sebuah contoh konfigurasi untuk backend berdasarkan python-memcached dengan batasan sebuah ukuran obyek dari 2 MB:
CACHES = {\n 'default': {\n 'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',\n 'LOCATION': '127.0.0.1:11211',\n 'OPTIONS': {\n 'server_max_value_length': 1024 * 1024 * 2,\n }\n }\n}\nIni adalah sebuah contoh konfigurasi untuk backend berdasarkan pylibmc yang mengadakan protokol biner, autentifikasi SASL, dan suasana perilaku 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}\nSekali cache disetel, cara termudah menggunakan cacge adalah cache situs anda seluruhnya. Anda akan butuh menambahkan 'django.middleware.cache.UpdateCacheMiddleware' dan 'django.middleware.cache.FetchFromCacheMiddleware' ke pengaturan MIDDLEWARE anda, seperti di contoh ini:
MIDDLEWARE = [\n 'django.middleware.cache.UpdateCacheMiddleware',\n 'django.middleware.common.CommonMiddleware',\n 'django.middleware.cache.FetchFromCacheMiddleware',\n]\nKemudian, tambah pengaturan dibutuhkan berikut ke berkas pengaturan Django anda:
\nCACHE_MIDDLEWARE_ALIAS -- nama lain tembolok untuk digunakan untuk penyimpanan.
CACHE_MIDDLEWARE_SECONDS -- Jumlah dari detik setiap halaman harus disimpan.
CACHE_MIDDLEWARE_KEY_PREFIX -- jika cacge dibagi lintas banyak situs menggunakan pemasangan Django sama, setel ke nama dari situs, atau beberapa string lain yang unik pada instance Django ini, untuk mencegah tabrakan kunci. Gunakan sebuah string kosong jika anda tidak peduli.
FetchFromCacheMiddleware cache tanggapan GET dan HEAD dengan keadaan 200, dimana kepala permintaan dan tanggapan diizinkan. Tanggapan pada permintaan untuk URL sama dengan parameter permintaan berbeda dianggap menjadi halaman unik dan di cache terpisah. Middleware ini mengharapkan bahwa sebuah permintaan HEAD dijawab dengan kepala tanggapan sesuai seperti permintaan GET berkaitan; dalam hal ini itu dapat mengembalikan sebuah tanggapan GET cache untuk permintaan HEAD.
Additionally, UpdateCacheMiddleware automatically sets a few headers in\neach HttpResponse which affect downstream caches:
Setel kepala Expires ke tanggal/waktu saat ini ditambah menentukan CACHE_MIDDLEWARE_SECONDS.
Setel kepala Cache-Control untuk memberikan umur maksimal untuk halaman -- kembali, dari pengaturan CACHE_MIDDLEWARE_SECONDS.
Lihat Middleware untuk lebih pada middleware
\nJika sebuah tampilan menyetel waktu kadaluarsa cache nya sendiri (yaitu itu mempunyai bagian max-age di kepala Cache-Control nya) kemudian halaman akan di cache sampai waktu kadaluarsa, daripada CACHE_MIDDLEWARE_SECONDS. menggunakan penghias di django.views.decorators.cache anda dapat dengan mudah mensetel sebuah waktu kadaluarsa tampilan (menggunakan penghias cache_control()) atau meniadakan cache untuk sebuah tampilan (menggunakan penghias never_cache() decorator). Lihat bagian using other headers pada penghias ini.
Jika USE_I18N`disetel menjadi ``True` kemudian membangkitkan kunci cache akan menyertakan nama dari language aktif -- lihat juga Bagaimana Django menemukan pilihan bahasa). Ini mengizinkan anda dengan mudah cache situs banyak bahasa tanpa harus membuat kunci cache anda sendiri.
Kunci-kunci cache juga menyertakan language aktif ketika USE_L10N disetel menjadi True dan current time zone ketika USE_TZ disetel menjadi True.
A more granular way to use the caching framework is by caching the output of\nindividual views. django.views.decorators.cache defines a cache_page\ndecorator that will automatically cache the view's response for you:
from django.views.decorators.cache import cache_page\n\n@cache_page(60 * 15)\ndef my_view(request):\n ...\ncache_page mengambil argumen tunggal: waktu habis cacge, dalam detik. Di contoh diatas, hasil dari tampilan my_view() akan di cache untuk 15 menit. (catah bahwa kami telah menulis itu sebagai 60 * 15 untuk tujuan dapat dibaca. 60 * 15 akan di nilai menjadi 900 -- yaitu, 15 menit dikalikan oleh 60 detik per menit.)
The cache timeout set by cache_page takes precedence over the max-age\ndirective from the Cache-Control header.
Cache per-tampilan, seperti cache per-site, adalah diambil sebagai datum masukan kendali dari URL. Jika banyak titik URL pada tampilan sama, setiap URL akan di cache terpisah. Melanjutkan contoh my_view, jika URLconf anda terlihat seperti ini:
urlpatterns = [\n path('foo/<int:code>/', my_view),\n]\nkemudian permintaan pada /foo/1/ dan /foo/23/ akan di cache terpisah, seprti anda mungkin harapkan. Tetapi sekali URL tertentu (sebagai contoh, /foo/23/) telah diminta, permintaan berikut ke URL itu akan menggunakan cache.
cache_page dapat juga mengambil sebuah argumen kata kunci pilihan, cache, yang akan mengalihkan penghias menggunakan cache khusus (dari pengaturan CACHES anda) ketika cache menampilkan hasil. Secara awalan, cache default akan digunakan, tetapi anda dapat menentukan cache apapun anda inginkan:
@cache_page(60 * 15, cache="special_cache")\ndef my_view(request):\n ...\nAnda dapat juga menimpa awalan tembolok pada berdasarkan per-tampilan. cache_page mengambil sebuah pilihan argumen kata kunci, key_prefix, yang bekerja di cara yang sama seperti pengaturan CACHE_MIDDLEWARE_KEY_PREFIX untuk middleware. Itu dapat digunakan seperti ini:
@cache_page(60 * 15, key_prefix="site1")\ndef my_view(request):\n ...\nArgumen key_prefix dan cache mungkin ditentukan bersama-sama. Argumen key_prefix dan KEY_PREFIX ditentukan dibawah CACHES akan digabungkan.
Additionally, cache_page automatically sets Cache-Control and\nExpires headers in the response which affect downstream caches.
Contoh-contoh di bagian sebelumnya telah di kode-keraskan fakta yang tampilan di cache, karena cache_page merubah fungsi my_view di tempat. Pendakan ini memasangkan tampilan anda ke sistem cache, yang tidak sesuai untuk beberapa alasan. Sebagai contoh, anda mungkin ingin menggunakan kembali fungsi tampilan pada lainnya, situs tidak-cache, atau anda mungkin ingin menyebarkan tampilan pada orang yang mungkin ingin menggunakan mereka tanpa sedang di cache. Pemecahan pada masalah ini adalah menentukan cache per-tampilan di URLconf daripada dekat ke fungsi tampilan mereka sendiri.
You can do so by wrapping the view function with cache_page when you refer\nto it in the URLconf. Here's the old URLconf from earlier:
urlpatterns = [\n path('foo/<int:code>/', my_view),\n]\nIni adalah hal yang sama, dengan my_view dibungkus di cache_page:
from django.views.decorators.cache import cache_page\n\nurlpatterns = [\n path('foo/<int:code>/', cache_page(60 * 15)(my_view)),\n]\nJika anda sedang mengejar lebih kendali, anda dapat juga cache fragmen cetakan menggunakan etiket cetakan cache. Untuk memberikan akses cetakan anda ke etiket ini, taruh {% load cache %} dekat atas dari cetakan anda.
Etiket cetakan {% cache %} menyimpan isi dari blok untuk sejumlah waktu yang diberikan. Itu mengambil setidaknya dua argumen: waktu habis cache, dalam detik, dan nama untuk memberikan bagian cache. Bagian di simpan selamanya jika waktu habis adalah None. Nama akan diambil dengan adanya, jangan menggunakan sebuah variabel. Sebagai contoh:
{% load cache %}\n{% cache 500 sidebar %}\n .. sidebar ..\n{% endcache %}\nTerkadang anda mungkin ingin menyimpan banyak salinan dari bagian tergantung pada beberapa dinamis data yang muncul didalam bagian. Sebagai contoh, anda mungkin ingin memisahkan salinan tersimpan dari batang sisi digunakan dalam contoh sebelumnya untuks etiap pengguna dari situs anda. Lakukan ini dengan melewatkan satu atau lebih argumen tambahan, yang mungkin berupa variabel dengan atau tanpa penyaring, pada etiket cetakan {% cache %} pada mencirikan secara unik bagian cache:
{% load cache %}\n{% cache 500 sidebar request.user.username %}\n .. sidebar for logged in user ..\n{% endcache %}\nJika USE_I18N disetel menjadi True cache middleware per-situs akan respect the active language. Untuk etiket cetakan cache anda dapat menggunakan satu dari translation-specific variables tersedia di cetakan untuk mencapai hasil sama:
{% 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 %}\nCache waktu habis dapat berupa sebuah variabel cetakan, selama variabel cetakan mengatasi nilai integer. Sebagai contoh, jika variabel cetakan my_timeout disetel menjadi nilai 600, kemudian dua contoh berikut adalah setara:
{% cache 600 sidebar %} ... {% endcache %}\n{% cache my_timeout sidebar %} ... {% endcache %}\nThis feature is useful in avoiding repetition in templates. You can set the\ntimeout in a variable, in one place, and reuse that value.
\nSecara awalan, etiket cache akan mencoba menggunakan cache dipanggil "template_fragments". Jika tidak ada cache seperti itu ada, itu akan kembali menggunakan cache awalan. Anda mungkin memilih sebuah backend cache bergantian untuk digunakan dengan argumen kata kunci using, yang harus berupa argumen terakhir ke etiket.
{% cache 300 local-thing ... using="localcache" %}\nItu adalah dianggap sebuah kesalahan untuk menentukan sebuah nama cache yang tidak dikonfigurasi.
\nJika anda ingin mengambil kunci cache digunakan untuk cache bagian, anda dapat menggunakan make_template_fragment_key. fragment_name adalah sama sebagai argumen kedua pada etiket cetakan cache; vary_on adalah sebuah daftar dari semua argumen tambahan dilewatkan etiket. Fungsi ini dapat berguna untuk membatalkan atau menimpa cache barang, sebagai contoh:
>>> 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\nTerkadang, cache sebuah seluruhnya halaman dibangun tidak mendapatkan anda sangat banyak, faktanya, nyaman berlebihan.
\nMungkin, sebagai contoh, situs anda menyertakan sebuah tampilan yang hasilnya bergantung pada beberpa permintaan mahal, hasil dari yang berubah pada rentang berbeda. Dalam kasus ini, itu akan tidak sesuai menggunakan cache halaman-penuh yang strategi cache per-situs atau per-tampilan tawarkan, karena anda tidak ingin cache keseluruhan hasil (sejak beberapa data sering berubah), tetapi anda akan masih ingin cache hasil yang jarang berubah.
\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 about\npickling.)
\nAnda dapat mengakses cache dikonfigurasikan di pengaturan CACHES melalui obyek seperti-kamus: django.core.cache.caches. Permintaan berulang untuk nama lain sama di thread sama akan mengembalikab obyek sama.
>>> from django.core.cache import caches\n>>> cache1 = caches['myalias']\n>>> cache2 = caches['myalias']\n>>> cache1 is cache2\nTrue\nJika kunci yang dinamai tidak ada, InvalidCacheBackendError akan muncul.
Untuk menyediakan thread-safety, sebuah instance berbeda dari backend cache akan dikembalikan untuk setiap thread.
\nSebagai sebuah jalan pintas, cache awalan tersedia sebagai django.core.cache.cache:
>>> from django.core.cache import cache\nObyek ini setara terhadap caches['default'].
Antarmuka dasar adalah:
\n>>> cache.set('my_key', 'hello, world!', 30)\n>>> cache.get('my_key')\n'hello, world!'\nkey harus berupa sebuah str, dan value dapat berupa obyek Python picklable.
Argumen timeout adalah pilihan dan awalan pada argumen timeout dari backend sesuai di pengaturan CACHES (dijelaskan diatas). Itu adalah jumlah nilai kedua harus disimpan di cache. Melewatkan di None untuk timeout akan cache nilai selamanya. Sebuah timeout dari 0 tidak akan cache nilai.
Jika obyek tidak ada di cache, cache.get() mengembalikan None:
>>> # Wait 30 seconds for 'my_key' to expire...\n>>> cache.get('my_key')\nNone\nIf you need to determine whether the object exists in the cache and you have\nstored a literal value None, use a sentinel object as the default:
>>> 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() dapat mengambil sebuah argumen default. Ini menentukan nilai mana untuk dikembalikan jika obyek tidak ada di cache:
>>> cache.get('my_key', 'has expired')\n'has expired'\nUntuk menambahkan sebuah kunci hanya jika itu tidak ada, gunakan metode add(). Itu mengambil parameter sama seperti set(), tetapi itu tidak akan mencoba memperbaharui cache jika kunci ditentukan sudah ada:
>>> cache.set('add_key', 'Initial value')\n>>> cache.add('add_key', 'New value')\n>>> cache.get('add_key')\n'Initial value'\nJika anda butuh mengetahui apakah add() menyimpan sebuah nilai di cache, anda dapat memeriksa nilai kembalian. Itu akan mengembalikan True jika nilai telah disimpan, False sebaliknya.
If you want to get a key's value or set a value if the key isn't in the cache,\nthere is the get_or_set() method. It takes the same parameters as get()\nbut the default is set as the new cache value for that key, rather than\nreturned:
>>> cache.get('my_new_key') # returns None\n>>> cache.get_or_set('my_new_key', 'my new value', 100)\n'my new value'\nAnda dapat juga melewatkan callable apapun sebagai nilai awalan:
\n>>> import datetime\n>>> cache.get_or_set('some-timestamp-key', datetime.datetime.now)\ndatetime.datetime(2014, 12, 11, 0, 15, 49, 457920)\nAda juga sebuah antarmuka get_many() yang hanya mengenai cache sekali. get_many() megnembalikan sebuah kamus dengan semua kunc-i-kunci anda minta untuk yang sebenarnya ada di cache (dan belum kadaluarsa):
>>> 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}\nUntuk menyetel banyak nilai lebih efesien, gunakan set_many() untuk melewatkan sebuah kamus dari pasangan kunci-nilai:
>>> cache.set_many({'a': 1, 'b': 2, 'c': 3})\n>>> cache.get_many(['a', 'b', 'c'])\n{'a': 1, 'b': 2, 'c': 3}\nSeperti cache.set(), set_many() mengambil sebuah pilihan parameter timeout.
Pada backend didukung (memcached), set_many() megnembalikan sebuah daftar dari kunci-kunci yang gagal dimasukkan.
You can delete keys explicitly with delete() to clear the cache for a\nparticular object:
>>> cache.delete('a')\nTrue\ndelete() returns True if the key was successfully deleted, False\notherwise.
Jika anda ingin membersihkan seikat kunci sekaligus, delete_many() dapat mengambil sebuah daftar dari kunci untuk dibersihkan:
>>> cache.delete_many(['a', 'b', 'c'])\nAkhirnya, jika anda ingin menghapus semua kunci di cache, gunakan cache.clear(). Hati-hatilah dengan ini; clear() akan memindahkan semua dari cache, bukan hanya kunci disetel oleh aplikasi anda.
>>> cache.clear()\ncache.touch() mensetel kadaluarsa baru untuk sebuah kunci. Sebagai contoh, untuk memperbaharui sebuah kunci untuk kadaluarsa 10 detik dari sekarang:
>>> cache.touch('a', 10)\nTrue\nLike other methods, the timeout argument is optional and defaults to the\nTIMEOUT option of the appropriate backend in the CACHES setting.
touch() mengembalikan True jika kunci berhasil disentuh, False sebaliknya.
Anda juga dapat menaikkan atau menurunkan kunci yang sudah ada menggunakan metode incr() atau decr(), masing-masing. Secara awalan, nilai cache yang ada akan dinaikkan atau diturunkan oleh 1. Nilai-nilai menaikkan/menurunkan lain dapat ditentukan dengan menyediakan sebuah argumen pada panggilan menaik/menurun. Sebuah ValueError akan dimuncukan untuk menaik atau menurun kunci cache tidak ada.:
>>> 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\nAnda dapat menutup hubungan ke cache anda dengan close() jika diterapkan oleh backend cache.
>>> cache.close()\nJika anda sedang berbagi sebuah instance cache diantara peladen, atau diantara lingkungan produksi dan pengembangan anda, itu memungkinkan untuk data cache oleh satu peladen untuk digunakan oleh peladen lain. Jika bentuk dari data cache berbeda diantara peladen, ini dapat membawa ke sangat keras dari mengenal masalah-masalah.
\nUntuk mencegah ini, Django menyediakan kemampuan untuk mengawali semua kunci cache digunakan oleh peladen. Ketika kunci cacge tertentu disimpan atau diambil, Django akan secara otomatis mengawali kunci cache dengan nilai dari pengaturan cache KEY_PREFIX.
Dengan memastikan setiap instance Django mempunyai KEY_PREFIX berbeda, anda dapat memastikan bahwa akan tidak ada tubrukan di nilai-nilai cache.
Ketika anda merubah menjalankan kode yang menggunakan nilai cache, anda mungkin butuh membersihkan nilai-nilai cache yang ada. Cara termudah melakukan ini adalah membilas keseluruhan cache, tetapi ini dapat membawa ke kehilangan nilai cache yang masih sah dan berguna.
\nDjango menyediakan cara terbaik pada nilai-nilai cache masing-masing sasaran. Kerangka kerja cache Django mempunyai penciri versi lebar-sistem, ditentukan menggunakan pengaturan cache VERSION. Nilai dari pengaturan ini secara otomatis dipadukan dengan awalan cache dan kunci cache disediakan-pengguna untuk mendapatkan kunci cache akhir.
Secara awalan, apapun permintaan kunci akan secara otomaris menyertakan versi kunci cache awalan situs. Bagaimanapun, fungsi cache primitif semua menyertakan sebuah argumen version, jadi anda dapt menentukan versi kunci cache tertentu untuk disetel atau didapatkan. Sebagai contoh:
>>> # 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!'\nVersi dari kunci tertentu ini dapat dinaikkan dan diturunkan menggunakan metode incr_version() dan decr_version() Ini mengadakan kunci-kunci tertentu untuk bertemu ke versi baru, meminggalkan kunci-kunci lain tidak terpengaruh. Melanjutkan contoh sebelumnya kami:
>>> # 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!'\nSeperti digambarkan di dua bagian sebelumnya, kunci cache disediakan oleh seorang pengguna tidak digunakan secara harfiah -- itu dipadukan dengan awalan cache dan versi kunci untuk menyediakan kunci cache akhir. Secara awalan, tiga bagian digabungkan menggunakan titik dua untuk menghasilkan string akhir:
\ndef make_key(key, key_prefix, version):\n return '%s:%s:%s' % (key_prefix, version, key)\nJika anda ingin memadukan bagian-bagian di cara berbeda, atau memberlakukan pengolahan lain menjadi kunci akhir (sebagai contoh, mengambil campuran inti dari bagian-bagian kunci), anda daat menyediakan sebuah fungsi kunci penyesuaian.
\nPengaturan cache KEY_FUNCTION menentukan jalur-bertitik pada sebuah fungsi mencocokan purwa-rupa dari make_key() diatas. Jika disediakan, fungsi kunci penyesuaian ini akan digunakan sebagai gantia dari kunci awalan memadukan fungsi.
Memcache, backend cache paling digunakan-umum produksi, tidak mengizinkan kunci cache lebih panjang dari 250 karakter atau mengandung ruang kosong atau kendali karakter, dan menggunakan kunci seperti itu akan menyebabkan sebuah pengecualian. Untuk mendorong kode ringan-cache menerbitkan sebuah peringatan (django.core.cache.backends.base.CacheKeyWarning) jika sebuah kecil yang dapat menyebabkan sebuah kesalahan pada memcache.
Jika anda sedang menggunakan backend produksi yang dapat menerima jangkauan lebih luas dari kunci (backend penyesuaian, atau satu dari bukan-memcache backend siap-pakai), dan ingin menggunakan jangkauan luas ini tanpa peringatan, anda dapat mendiamkan CacheKeyWarning dengan kode ini di modul management dari satu dari INSTALLED_APPS anda:
import warnings\n\nfrom django.core.cache import CacheKeyWarning\n\nwarnings.simplefilter("ignore", CacheKeyWarning)\nJika anda ingin daripada menyediakan penyesuaian logika pengecekan kunci untuk satu dari backend pasang-tetap, anda dapat mensubkelaskannya, timpa hanya metode validate_key, dan ikuti petunjuk untuk using a custom cache backend. Sebagai contoh, untuk melakukan ini untuk backend locmem, taruh kode ini di modul:
from django.core.cache.backends.locmem import LocMemCache\n\nclass CustomLocMemCache(LocMemCache):\n def validate_key(self, key):\n """Custom validation, raising exceptions or warnings as needed."""\n ...\n...dan menggunakan jalur Python bertitik pada kelas ini di bagain BACKEND dari pengaturan CACHES.
Sejauh ini, dokumen ini telah memfokuskan pada cache data anda sendiri. Tetapi jenis lain dari cache adalah berhubungan pada pengembangan Jaringan, juga: penampilan cache oleh cache "downstream". Ada sistem yang halaman cache untuk pengguna bahkan sebelum permintaan mencapai situs jaringan anda.
\nIni adalah sedikit contoh dari cache hilir:
\nISP anda mungkin cache halaman tertentu, jadi jika anda diminta sebuah halaman dari https://example.com/, ISP anda akan mengirim anda halaman tanpa mengakses example.com langsung. Perawat dari example.com tidak mempunyai pengetahuan dari cache ini; ISP duduk diantara example.com dan peramban Jaringan anda, menangani semua cache secara transparan.
Situs jaringan Django anda mungkin duduk dibelakang cache proxy, seperti Squid Web Proxy Cache (http://www.squid-cache.org/), yang cache halaman untuk penampilan. Dalam kasus ini, setiap permintaan pertama akan ditangani oleh proxy, dan itu akan dilewatkan ke aplikasi anda jika dibutuhkan.
Peramban Jaringan anda cache halaman, juga. jika halaman Jaringan mengirim kepala sesuai, peramban anda akan menggunakan salinan cache lokal untuk permintaan berikutnya ke halaman itu, tanpa bahkan menghubungi halaman jaringan kembali untuk melihat apakah itu telah berubah.
Cache hilir adalah tambahan efesiensi yang bagus, tetapi ada bahaya terhadap itu: Banyak isi halaman Jaringan dibedakan berdasarkan pada autentifikasi dan rumah dari variabel lain, dan sistem cache yang dengan buta menyimpan halaman berdasarkan semata-mata pada URL dapat di membongkar data tidak benar atai sensitif ke pengungjung selanjutnya ke halaman-halaman itu.
\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.
\nUntungnya, HTTP menyediakan sebuah pemecahan pada masalah ini. Sejumlah kepala HTTP ada untuk memberikan petunjuk cache hilir untuk membedakan isi cache mereka bergantung pada variabel-variabel ditunjuk, dan memberitahu mekanisme cache tidak meng cache halaman tertentu. Kami akan mencari beberapa kepala ini di bagian-bagian yang mengikuti.
\nVaryLink to this heading#Kepala Vary menentukan permintaan mana kepala sebuah mekanisme cache harus diambil kedalam akun ketika membangun kunci cachenya. Sebagai contoh, jika isi dari halaman Jaringan bergantung pada pilihan bahasa pengguna, halaman dikatakan "vary on language."
Secara awalan, sistem cache Django membuat kunci cache nya menggunakan URL sepenuhnya-memenuhi syarat diminta -- sebagai contoh, "https://www.example.com/stories/2005/?order_by=author". Ini berarti setiap permintaan ke URL itu akan menggunakan versi cache sama, tanpa memperhatikan dari perbedaan agen-pengguna seperti kue atau pilihan bahasa. Bagaimanapun, jika halaman ini menghasilkan isi berbeda berdasarkan pada beberapa perbedaan di kepala permintaan -- seperti sebuah kue, atau sebuah bahasa, atau agen-pengguna -- anda akan butuh menggunakan kepala Vary untuk memberitahu mekanisme cache yang keluaran halaman bergantung pada hal-hal tersebut.
Untuk melakukan ini di Django, gunakan penghias tampilan django.views.decorators.vary.vary_on_headers() nyaman, seperti begitu:
from django.views.decorators.vary import vary_on_headers\n\n@vary_on_headers('User-Agent')\ndef my_view(request):\n ...\nDi kasus ini, mekanisme cache (seperti middleware cache sendiri Django) akan cache sebuah versi terpisah dari halaman untuk setiap agen-pengguna unik.
\nKeuntungan menggunakan penghias vary_on_headers daripada secara manual mengatur kepala Vary (menggunakan sesuatu seperti response['Vary'] = 'user-agent') adalah bahwa penghias adds pada kepala Vary (yang mungkin sudah ada), daripada mengatur itu dari goresan dan berpeluang mengutamakan apapun yang telah ada disana.
Anda dapat melewatkan banyak kepala pada vary_on_headers():
@vary_on_headers('User-Agent', 'Cookie')\ndef my_view(request):\n ...\nIni memberitahukan cache hilir untuk vary pada kedua, yang berarti setiap perpaduan dari agen-pengguna dan kue akan mendapatkan nilai cache nya sendiri. Sebagai contoh, sebuah permintaan dengan agen-pengguna Mozilla dan nilai kue foo=bar akan dianggap berbeda dari permintaan dengan agen-pengguna Mozilla dan nilai kue foo=ham.
Karena beragam pada kue adalah sangat umum, ada sebuah penghias django.views.decorators.vary.vary_on_cookie(). Kedua tampilan ini adalah setara:
@vary_on_cookie\ndef my_view(request):\n ...\n\n@vary_on_headers('Cookie')\ndef my_view(request):\n ...\nKepala anda lewatkan ke vary_on_headers tidak hal-hal sensitif; "User-Agent" adalah hal sama seperti "user-agent".
Anda dapat juga menggunakan fungsi pembantu, django.utils.cache.patch_vary_headers(), secara langsung. Fungsi ini menyetel, atau menambah ke, Vary header. Sebagai contoh:
from django.shortcuts import render\nfrom django.utils.cache import patch_vary_headers\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 mengambil sebuah instance HttpResponse sebagai argumen pertamanya dan sebuah list/tuple dari nama-nama kepala kasus-tidak-peka sebagai argumen keduanya.
Untuk lebih pada kepala Vary, lihat official Vary spec.
\nMasalah lain dengan cache adalah pribadi dari data dan pertanyaan dari dimana data harus disimpan di cache urutan kebawah.
\nSeorang pengguna biasanya menghadapi dua hal dari cache: cache perambannya mereka (sebuah cache pribadi) dan cache penyedia mereka (sebuah cache umum). Sebuah cache umum digunakan oleh banyak pengguna dan dikendalikan oleh seseorang lain. Sikap ini masalah dengan data sensitif--anda tidak ingin mengatakan, katakan, nomor akun bank anda disimpan di cache umum. Sehingga aplikasi Jaringan butuh cara memberitahu cache yang data adalah pribadi dan mana yang umum.
\nPemecahannya adalah menunjukkan cache halaman harus berupa "private". Untuk melakukan ini di Django, gunakan penghias tampilan cache_control(). Contoh:
from django.views.decorators.cache import cache_control\n\n@cache_control(private=True)\ndef my_view(request):\n ...\nPenghias ini merawat dari mengirim keluar kepala HTTP sesuai dibelakang layar.
\nCatat bahwa pengaturan kendali cache "pribadi" and "umum" adalah saling eksklusif. Penghias memastikan bahwa petunjuk "umum: dipindahkan jika "pribadi" harus disetel (dan sebaliknya). Sebuah contoh penggunaan daro dua petunjuk akan menjadi sebuah situs blog yang menawarkan kedua masukan pribadi dan umum. Masukan umum mungkin di cache pada cache berbagi apapun. Kode berikut menggunakan patch_cache_control(), cara manual untuk merubah kepala kendali cache (itu adalah secara internal dipanggil oleh penghias cache_control()):
from django.views.decorators.cache import patch_cache_control\nfrom django.views.decorators.vary import vary_on_cookie\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\nAnda dapat mengendalikan cache hilir di cara lain demukian juga (lihat RFC 7234 untuk rincian pada cache HTTP). Sebagai contoh, bahkan jika anda tidak menggunakan kerangka kerja cache sisi-peladen, anda dapat masih meberitahu klien untuk cache sebuah tampilan untuk sejumlah waktu tertentu dengan petunjuk max-age:
\nfrom django.views.decorators.cache import cache_control\n\n@cache_control(max_age=3600)\ndef my_view(request):\n ...\n(Jika anda melakukan menggunakan middleware cache, itu sudah disetel max-age dengan nilai dari pengaturan CACHE_MIDDLEWARE_SECONDS. Dalam kasus itu, penyesuaian max-age dari penghias cache_control() akan mengambil hak lebih tinggi, dan nilai-nlai kepala akan digabung dengan benar.)
Cache-Control sah apapun menangganpi petunjuk adalah sah di cache_control(). Ini adalah beberapa contoh lebih:
no_transform=True
must_revalidate=True
stale_while_revalidate=num_seconds
no_cache=True
Daftar penuh dari arahan dikenal dapat ditemukan di IANA registry (catat bahwa tidak semua dari mereka memberlakukan terhadap tanggapan).
\nJika anda ingin menggunakan kepala untuk meniadakan cache sama sekali, never_cache() adalah tampilan penghias yang menambahkan kepala-kepala untuk memastikan tanggapan tidak akan di cache oleh peramban atau cache lain. Contoh:
from django.views.decorators.cache import never_cache\n\n@never_cache\ndef myview(request):\n ...\nMIDDLEWARELink to this heading#Jika anda menggunakan middleware cache, itu adalah penting untuk menaruh setiap setengah di tempat kanan dalam pengaturan MIDDLEWARE, Itu karena middleware cache butuh mengetahui kepala-kepala mana yang digunakan oleh cary pentimpan cache. Middleware selau menambahkan sesuatu ke kepala tanggapan Vary ketika itu dapat.
UpdateCacheMiddleware berjalan selama fase tanggapan, dimana middleware berjalan di membalikkan urutan, jadi sebuah barang pada teratas dari daftar menjalankan terakhir selama fase tanggapan. Dengan demikian, anda butuh memastikan bahwa UpdateCacheMiddleware muncul sebelum middleware lain apapun yang mungkin menambahkan sesuatu ke kepala Vary. Modul middleware berikut melakukannya:
SessionMiddleware menambah Cookie
GZipMiddleware menambah Accept-Encoding
LocaleMiddleware menambah Accept-Language
FetchFromCacheMiddleware, di sisi lain, berjalan selama fase permintaan, dimana middleware diberlakukan pertama-ke-terakhir, jadi sebuah barang pada teratas dari daftar berjalan pertama selama fase permintaan. FetchFromCacheMiddleware juga butuh menjalankan setelah middleware lain memperbaharui kepala vary, jadi FetchFromCacheMiddleware harus berupa setelah barang apapun yang melakukannya.