Pertukaran mendasar dalam situs web dinamis adalah, mereka dinamis. Setiap kali pengguna meminta halaman, peladen jaringan membuat segala macam perhitungan -- mulai dari permintaan basisdara hingga membangun cetakan hingga logika bisnis -- untuk membuat halaman yang dilihat pengunjung situs anda. Ini jauh lebih mahal, dari perspektif pemrosesan-overhead, daripada pengaturan peladen read-a-file-off-the-filesystem 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\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.
Itu adalah dimana cache datang.
\nMeng-cache sesuatu berarti menyimpan hasil perhitungan yang mahal sehingga anda tidak perlu melakukan perhitungan di lain waktu. Berikut ini beberapa kodesemu yang menjelaskan cara kerjanya untuk halaman web yang dibuat secara dinamis:
\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 baik dengan cache "hilir", seperti Squid dan cache berbasis browser. Ini adalah jenis cache yang tidak anda kontrol secara langsung, tetapi anda dapat memberikan petunjuk (melalui header HTTP) tentang bagian mana dari situs anda yang harus di-cache, dan bagaimana caranya.
\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.
Memcached adalah server cache yang sepenuhnya berbasis memori, awalnya dikembangkan untuk menangani beban tinggi di LiveJournal.com dan kemudian di-open-source oleh Danga Interactive. Ini digunakan oleh situs-situs seperti Facebook dan Wikipedia untuk mengurangi akses basisdata dan secara dramatis meningkatkan kinerja 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 sendiri, anda harus memasang pengikatan Memcached. Ada beberapa binding Python Memcached yang tersedia; keduanya didukung oleh Django adalah pylibmc dan pymemcache.
\nUntuk menggunakan Memcache dengan Django:
\nSetel BACKEND 1 ke django.core.cache.backends.memcached.PyMemcacheCache atau django.core.cache.backends.memcached.PyLibMCCache (tergantung pengikatan memcached pilihan anda)
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, Memcached berjalan di localhost (127.0.0.1) port 11211, menggunakan pengikatan pymemcache:
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",\n "LOCATION": "127.0.0.1:11211",\n }\n}\nDalam contoh ini, Memcached tersedia melalui file soket Unix lokal /tmp/memcached.sock menggunakan pengikat pymemcache:
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",\n "LOCATION": "unix:/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.PyMemcacheCache",\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.PyMemcacheCache",\n "LOCATION": [\n "172.19.26.240:11211",\n "172.19.26.242:11212",\n "172.19.26.244:11213",\n ],\n }\n}\nSecara awalan, backend PyMemcacheCache menyetel pilihan berikut (anda dapat menimpa mereka dalam OPTIONS):
"OPTIONS": {\n "allow_unicode_keys": True,\n "default_noreply": False,\n "serde": pymemcache.serde.pickle_serde,\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.
\nRedis adalah basisdata dalam memori yang dapat digunakan untuk caching. Untuk memulai, anda memerlukan server Redis yang berjalan secara lokal atau di mesin jarak jauh.
\nSetelah menyetel peladen Redis, anda akan butuh memasang ikatan Python untuk Redis. redis-py adalah ikatan didukung secara asli oleh Django. Memasang paket hiredis-py juga dianjurkan.
\nUntuk menggunakan Redis sebagai backend cache anda dengan Django:
\nSetel BACKEND menjadi 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.
Sebagai contoh, jika Redis berjalan pada 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}\nSeringkali peladen Redis dilindungi dengan autentikasi. Untuk memasukkan nama pengguna dan kata sandi, tambahkan di LOCATION bersama dengan URL:
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.redis.RedisCache",\n "LOCATION": "redis://username:password@127.0.0.1:6379",\n }\n}\nJika anda memiliki beberapa peladen Redis yang diatur dalam suasana replikasi, anda dapat menentukan peladen baik sebagai string yang dipisahkan titik koma atau koma, atau sebagai daftar. Saat menggunakan banyak peladen , operasi tulis dilakukan di peladen pertama (pemimpin). Operasi baca dilakukan di peladen lain (replika) yang dipilih secara acak
\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 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}\nTidak seperti backend cache lainnya, cache basisdata tidak mendukung pemusnahan otomatis masukan yang kedaluwarsa di tingkat basisdata. Sebagai gantinya, masukan cache yang kedaluwarsa akan diambil setiap kali add(), set(), atau touch() dipanggil.
Sebelum menggunakan cache basisdata, anda harus membuat tabel cache 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.
Dan jika anda tidak menggunakan backend cache basisdata, anda tidak perlu khawatir untuk menyediakan instruksi perutean untuk model cache basisdata.
\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.
\nPastikan direktori yang ditunjuk oleh pengaturan ini ada dan dapat dibaca dan ditulis, atau dapat dibuat oleh pengguna sistem tempat peladen jaringan anda berjalan. Melanjutkan contoh di atas, jika peladen anda berjalan sebagai pengguna apache, pastikan direktori /var/tmp/django_cache ada dan dapat dibaca dan ditulis oleh pengguna apache, atau bahwa dapat dibuat oleh pengguna 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).
\nPerhatikan bahwa setiap proses akan memiliki instance tembolok pribadinya sendiri, yang berarti tidak ada caching lintas proses yang memungkinkan. Ini juga berarti tembolok memori lokal tidak terlalu hemat memori, jadi ini mungkin bukan pilihan yang baik untuk lingkungan produksi. Ini bagus untuk pengembangan.
\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 membuat backend anda sendiri, anda dapat menggunakan backend tembolok standar sebagai penerapan acuan. Anda akan menemukan kode di direktori django/core/cache/backends/ dari sumber Django.
\nCatatan: Tanpa alasan yang benar-benar kuat, seperti host yang tidak mendukungnya, anda harus tetap menggunakan backend tembolok yang disertakan dengan Django. Mereka telah diuji dengan baik dan didokumentasikan dengan baik.
\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 Memcached dan Redis melewatkan isi OPTIONS sebagai argumen kata kunci ke constructor klien, mengizinkan untuk kendali tingkatan lebih dari perilaku klien. Contoh penggunaan, lihat dibawaah.
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": {"MAX_ENTRIES": 1000},\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}\nBerikut adalah contoh konfigurasi untuk backend berbasis pymemcache yang memungkinkan penyatuan klien (yang dapat meningkatkan performa dengan menjaga klien tetap terhubung), memperlakukan kesalahan memcache/jaringan sebagai tembolok yang hilang, dan menyetel bendera``TCP_NODELAY`` pada soket koneksi
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}\nHere's an example configuration for a redis based backend that selects\ndatabase 10 (by default Redis ships with 16 logical databases), and sets a\ncustom connection pool class (redis.ConnectionPool is used by default):
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}\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 -- Angka integer dari setiap halaman kedua harus di cache.
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.
Selain itu, UpdateCacheMiddleware otomatis mensetel beberapa kepala dalam setiap HttpResponse yang mempengaruhi 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 cache juga menyertakan current time zone ketika USE_TZ disetel menjadi True.
Cara yang lebih terperinci untuk menggunakan kerangka caching adalah dengan menyimpan keluaran dari tampilan individual ke dalam caching. Django.views.decorators.cache mendefinisikan dekorator cache_page yang akan secara otomatis meng-cache respons tampilan untuk anda:
from django.views.decorators.cache import cache_page\n\n\n@cache_page(60 * 15)\ndef my_view(request): ...\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.)
Batas waktu tembolok yang ditetapkan oleh cache_page lebih diutamakan daripada direktif max-age dari kepala Cache-Control.
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): ...\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): ...\nArgumen key_prefix dan cache mungkin ditentukan bersama-sama. Argumen key_prefix dan KEY_PREFIX ditentukan dibawah CACHES akan digabungkan.
Selain itu, cache_page otomatis mensetel Cache-Control dan kepala Expires dalam tanggapan yang mempengaruhi 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.
Anda dapat melakukannya dengan membungkus fungsi tampilan dengan cache_page saat anda merujuknya di URLconf. Inilah URLconf lama dari sebelumnya
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 %}\nFitur ini berguna untuk menghindari pengulangan pada cetakan. Anda dapat menyetel batas waktu dalam variabel, di satu tempat, dan menggunakan kembali nilai tersebut.
\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.
\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\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\nabout pickling.)
Anda 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 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 objek tidak ada dalam cache, cache.get() mengembalikan None:
>>> # Wait 30 seconds for 'my_key' to expire...\n>>> cache.get("my_key")\nNone\nJIka anda butuh menentukan apakah objek ada dalam cache dan anda telah menyimpan nilai harfiah None, gunakan objek penjaga sebagai awalan:
>>> 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() can take a default argument. This specifies which value to\nreturn if the object doesn't exist in the cache:
>>> cache.get("my_key", "has expired")\n'has expired'\nTo add a key only if it doesn't already exist, use the add() method.\nIt takes the same parameters as set(), but it will not attempt to\nupdate the cache if the key specified is already present:
>>> 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 juga dapat melewatkan callable apapun sebagai nilai default:
\n>>> import datetime\n>>> cache.get_or_set("some-timestamp-key", datetime.datetime.now)\ndatetime.datetime(2014, 12, 11, 0, 15, 49, 457920)\nThere's also a get_many() interface that only hits the cache once.\nget_many() returns a dictionary with all the keys you asked for that\nactually exist in the cache (and haven't expired):
>>> 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}\nTo set multiple values more efficiently, use set_many() to pass a\ndictionary of key-value pairs:
>>> 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.
Anda dapat menghapus kunci secara eksplisit dengan delete() untuk membersihkan cache untuk objek tertentu:
>>> cache.delete("a")\nTrue\ndelete() returns True if the key was successfully deleted, False\notherwise.
If you want to clear a bunch of keys at once, delete_many() can take a list\nof keys to be cleared:
>>> 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() sets a new expiration for a key. For example, to update a key\nto expire 10 seconds from now:
>>> 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.
You can also increment or decrement a key that already exists using the\nincr() or decr() methods, respectively. By default, the existing cache\nvalue will be incremented or decremented by 1. Other increment/decrement values\ncan be specified by providing an argument to the increment/decrement call. A\nValueError will be raised if you attempt to increment or decrement a\nnonexistent cache key:
>>> 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.
By default, any key request will automatically include the site\ndefault cache key version. However, the primitive cache functions all\ninclude a version argument, so you can specify a particular cache\nkey version to set or get. For example:
>>> # 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!'\nThe version of a specific key can be incremented and decremented using\nthe incr_version() and decr_version() methods. This\nenables specific keys to be bumped to a new version, leaving other\nkeys unaffected. Continuing our previous example:
>>> # 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\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.
Django has developing support for asynchronous cache backends, but does not\nyet support asynchronous caching. It will be coming in a future release.
\ndjango.core.cache.backends.base.BaseCache has async variants of all\nbase methods. By convention, the asynchronous versions\nof all methods are prefixed with a. By default, the arguments for both\nvariants are the same:
>>> await cache.aset("num", 1)\n>>> await cache.ahas_key("num")\nTrue\nSo far, this document has focused on caching your own data. But another type\nof caching is relevant to web development, too: caching performed by\n"downstream" caches. These are systems that cache pages for users even before\nthe request reaches your website.
\nIni adalah sedikit contoh dari cache hilir:
\nWhen using HTTP, your ISP may cache\ncertain pages, so if you requested a page from http://example.com/, your\nISP would send you the page without having to access example.com directly.\nThe maintainers of example.com have no knowledge of this caching; the ISP\nsits between example.com and your web browser, handling all of the caching\ntransparently. Such caching is not possible under HTTPS as it would\nconstitute a man-in-the-middle attack.
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.
Your web browser caches pages, too. If a web page sends out the\nappropriate headers, your browser will use the local cached copy for\nsubsequent requests to that page, without even contacting the web page\nagain to see whether it has changed.
Downstream caching is a nice efficiency boost, but there's a danger to it:\nMany web pages' contents differ based on authentication and a host of other\nvariables, and cache systems that blindly save pages based purely on URLs could\nexpose incorrect or sensitive data to subsequent visitors to those pages.
\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#The Vary header defines which request headers a cache\nmechanism should take into account when building its cache key. For example, if\nthe contents of a web page depend on a user's language preference, the page is\nsaid to "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\n@vary_on_headers("User-Agent")\ndef my_view(request): ...\nDi kasus ini, mekanisme cache (seperti middleware cache sendiri Django) akan cache sebuah versi terpisah dari halaman untuk setiap agen-pengguna unik.
\nThe advantage to using the vary_on_headers decorator rather than manually\nsetting the Vary header (using something like response.headers['Vary'] =\n'user-agent') is that the decorator adds to the Vary header (which may\nalready exist), rather than setting it from scratch and potentially overriding\nanything that was already in there.
Anda dapat melewatkan banyak kepala pada vary_on_headers():
@vary_on_headers("User-Agent", "Cookie")\ndef my_view(request): ...\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): ...\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\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 informasi lebih lanjut tentang header Vary, lihat official Vary spec.
\n\n\nMasalah lain dengan cache adalah pribadi dari data dan pertanyaan dari dimana data harus disimpan di cache urutan kebawah.
\nA user usually faces two kinds of caches: their own browser cache (a private\ncache) and their provider's cache (a public cache). A public cache is used by\nmultiple users and controlled by someone else. This poses problems with\nsensitive data--you don't want, say, your bank account number stored in a\npublic cache. So web applications need a way to tell caches which data is\nprivate and which is public.
\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\n@cache_control(private=True)\ndef my_view(request): ...\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\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\nYou can control downstream caches in other ways as well (see RFC 9111 for\ndetails on HTTP caching). For example, even if you don't use Django's\nserver-side cache framework, you can still tell clients to cache a view for a\ncertain amount of time with the max-age\ndirective:
\nfrom django.views.decorators.cache import cache_control\n\n\n@cache_control(max_age=3600)\ndef my_view(request): ...\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\n@never_cache\ndef myview(request): ...\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.