Kerangka kerja penyimpanan Django

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.

Untuk kebanyakan aplikasi Jaringan, tambahan ini bukanlah hal yang besar. Kebanyakan aplikasi Jaringan bukan washingtonpost.com atau slashdot.org; mereka hanya situs kecil- ke ukuran-menengah dengan lalu lintas biasa saja. Tetapi untuk situs-situs lalu lintas menengah- ke tinggi, itu adalah mendasar memotong pengeluaran sebanyak mungkin.

Itu adalah dimana cache datang.

Untuk 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:

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

Django 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.

Django 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.

lihat juga

Cache Framework design philosophy menjelaskan sedikit dari keputusan rancangan dari kerangka kerja.

Mengatur tembolok

Sistem 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.

Pilihan cache anda masuk di pengaturan CACHES di berkas pengaturan anda. Ini adalah sebuah penjelasan dari semua nilai-nilai tersedia untuk CACHES.

Memcache

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.

Memcached 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.

Setelah memasang Memcached itu sendiri, anda akan butuh memasang ikatan Memcached. Ada beberapa ikatan Memcached Python tersedia; dua paling umum adalah python-memcached dan pylibmc.

Untuk menggunakan Memcache dengan Django:

  • Setel 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 = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': '127.0.0.1:11211',
    }
}

Dalam contoh ini, Memcache tersedia melalui berkas soket Unix lokal /tmp/memcached.sock menggunakan pengikatan python-memcached:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': 'unix:/tmp/memcached.sock',
    }
}

Ketika menggunakan mengikat pylibmc, jangan menyertakan awalan unix:/`

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.PyLibMCCache',
        'LOCATION': '/tmp/memcached.sock',
    }
}

Satu 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:

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

Di 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):

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

Sebuah 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.

Menembolok basisdata

Django dapat menyimpan data temboloknya dalam basisdata anda. Ini bekerja baik jika anda mendapatkan cepat, peladen basisdata diindeks baik.

Untuk menggunakan tabel basisdata sebagai backend tembolok anda:

  • Setel 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 = {
    'default': {
        'BACKEND': 'django.core.cache.backends.db.DatabaseCache',
        'LOCATION': 'my_cache_table',
    }
}

Membuat tabel tembolok

Sebelum menggunakan basisdata tembolok, anda harus membuat tabel tembolok dengan perintah ini:

python manage.py createcachetable

Ini 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.

Basisdata banyak

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:
    """A router to control all database cache operations"""

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

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

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

Jika anda tidak menentukan arah perute untuk model cache basisdata, backend cache akan menggunakan basisdata default.

Tentu saja, jika anda tidak menggunakan backend cache basisdata, anda tidak perlu khawatir tentang menyediakan petunjuk perutean untuk model cache basisdata.

Cache sistem berkas

Serial 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 = {
    'default': {
        'BACKEND': 'django.core.cache.backends.filebased.FileBasedCache',
        'LOCATION': '/var/tmp/django_cache',
    }
}

Jika anda berada di Windows, taruh huruf drive pada awal jalur, seperti ini:

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

Jalur 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.

Pastikan direktori menunjuk-ke oleh pengaturan ini ada dan dapat dibaca dan ditulis oleh pengguna sistem dibawah dimana peladen Jaringan anda berjalan. Melanjutkan contoh diatas, jika peladen anda berjalan sebagai pengguna apache, pastikan direktori /var/tmp/django_cache ada dan dapat dibaca dan ditulis oleh pengguna apache.

Cache memori-lokal

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 = {
    'default': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
        'LOCATION': 'unique-snowflake',
    }
}

Cache 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).

Catat bahwa setiap pengolahan akan mempunyai instance cache pribadi sendiri, yang berarti tidak ada cache lintas-pengolahan dimungkinkan. Ini jelas juga berarti cache memori lokal tidak secara khusus efesien-memori, jadi itu kemungkinan bukan pilihan bagus untuk lingkungan produksi. Itu adalah bagus untuk pengembangan.

Changed in Django 2.1:

Versi terlama menggunakan strategi pemusnahan acak-semu daripada LRU.

Cache tiruan (untuk pengembangan)

Akhirnya, Django datang dengan cache "dummy" yang tidak sebenarnya cache -- itu hanya menerapkan antarmuka cache tanpa melakukan apapun.

Ini 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 = {
    'default': {
        'BACKEND': 'django.core.cache.backends.dummy.DummyCache',
    }
}

Menggunakan backend cache penyesuaian

Selagi 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 = {
    'default': {
        'BACKEND': 'path.to.backend',
    }
}

Jika 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.

Catat: tanpa alasan yang sangat menarik, seperti sebuah rumah yang tidak mendukung mereka, anda harus menancapkan ke backend cache disertakan dengan Django. Mereka telah dicoba-baik dan mudah digunakan.

Argumen cache

Setiap 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.

  • VERSION: Nomor versi awalan untuk kunci-kunci cache dibangkitkan oleh peladen Django.

    Lihat the cache documentation untuk informasi lebih.

  • KEY_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.

Di contoh ini, backend sistem berkas sedang dikonfigurasikan dengan waktu habis dari 60 detik, dan kapasitas maksimal dari 1000 barang:

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

Ini adalah sebuah contoh konfigurasi untuk backend berdasarkan python-memcached dengan batasan sebuah ukuran obyek dari 2 MB:

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': '127.0.0.1:11211',
        'OPTIONS': {
            'server_max_value_length': 1024 * 1024 * 2,
        }
    }
}

Ini adalah sebuah contoh konfigurasi untuk backend berdasarkan pylibmc yang mengadakan protokol biner, autentifikasi SASL, dan suasana perilaku ketama:

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

Cache per-site

Sekali 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 = [
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
]

Catatan

Tidak, itu bukan salah ketik: middleware "update" harus pertama di daftar, dan middleware "fetch" harus di terakhir. Rincian sedikit mengaburkan, tetapi lihat Order of MIDDLEWARE dibawah jika anda ingin cerita penuh.

Kemudian, tambah pengaturan dibutuhkan berikut ke berkas pengaturan Django anda:

  • CACHE_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.

Tambahannya, UpdateCacheMiddleware otomatis menyetel sedikit kepala di setiap HttpResponse:

Lihat Middleware untuk lebih pada middleware

Jika 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.

Cache per-tampilan

django.views.decorators.cache.cache_page()

Sebuah cara lebih rinci menggunakan kerangka kerja cache adalah dengan cache keluaran dari tampilan tersendiri. django.views.decorators.cache menentukan sebuah penghias cache_page yang akan secara otomatis cache tanggapan tampilan untuk anda. Itu mudah digunakan:

from django.views.decorators.cache import cache_page

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

cache_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.)

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 = [
    path('foo/<int:code>/', my_view),
]

kemudian 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")
def my_view(request):
    ...

Anda 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")
def my_view(request):
    ...

Argumen key_prefix dan cache mungkin ditentukan bersama-sama. Argumen key_prefix dan KEY_PREFIX ditentukan dibawah CACHES akan digabungkan.

Menentukan cache per-tampilan di URLconf

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.

Melakukannya sangat mudah: cukup membungkus fungsi tampilan dengan cache_page ketika anda mengacu ke itu di URLconf. Ini adalah URLconf lama dari sebelumnya:

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

Ini adalah hal yang sama, dengan my_view dibungkus di cache_page:

from django.views.decorators.cache import cache_page

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

Cache bgian cetakan

Jika 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 %}
{% cache 500 sidebar %}
    .. sidebar ..
{% endcache %}
Changed in Django 2.0:

Versi-versi terlama tidak mengizinkan waktu habis None.

Terkadang 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 %}
{% cache 500 sidebar request.user.username %}
    .. sidebar for logged in user ..
{% endcache %}

Jika 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 %}
{% load cache %}

{% get_current_language as LANGUAGE_CODE %}

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

Cache 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 %}
{% cache my_timeout sidebar %} ... {% endcache %}

Fitur ini berguna dalam menghindari perulangan di cetakan. Anda dapat menyetel waktu habis di sebuah variabel, dalam satu tempat, dan hanya menggunakan nilai itu.

Secara 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" %}

Itu adalah dianggap sebuah kesalahan untuk menentukan sebuah nama cache yang tidak dikonfigurasi.

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

Jika 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
>>> from django.core.cache.utils import make_template_fragment_key
# cache key for {% cache 500 sidebar username %}
>>> key = make_template_fragment_key('sidebar', [username])
>>> cache.delete(key) # invalidates cached template fragment

API cache tingkat-bawah

Terkadang, cache sebuah seluruhnya halaman dibangun tidak mendapatkan anda sangat banyak, faktanya, nyaman berlebihan.

Mungkin, 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.

Untuk kasus-kasus seperti ini, Django mengeluarkan sederhana, API cache tingkat-bawah. Anda dapat menggunakan API ini untuk menyimpan obyek-obyek di cache dengan tingkatan apapun lebih rinci anda suka. Anda dapat cache obyek Python apapun yang dapat di pickle dengan aman: string, kamus, daftar dari obyek model, dan sebagainya. (Kebanyakan obyek-pbyek Python umum dapat di pickle; mengacu pada dokumentasi Python untuk informasi lebih mengenai pickle.)

Mengakses cache

django.core.cache.caches

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
>>> cache1 = caches['myalias']
>>> cache2 = caches['myalias']
>>> cache1 is cache2
True

Jika kunci yang dinamai tidak ada, InvalidCacheBackendError akan muncul.

Untuk menyediakan thread-safety, sebuah instance berbeda dari backend cache akan dikembalikan untuk setiap thread.

django.core.cache.cache

Sebagai sebuah jalan pintas, cache awalan tersedia sebagai django.core.cache.cache:

>>> from django.core.cache import cache

Obyek ini setara terhadap caches['default'].

Penggunaan dasar

Antarmuka dasar adalah:

cache.set(key, value, timeout=DEFAULT_TIMEOUT, version=None)
>>> cache.set('my_key', 'hello, world!', 30)
cache.get(key, default=None, version=None)
>>> cache.get('my_key')
'hello, world!'

key 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...
>>> cache.get('my_key')
None

Kami menyarankan terhadap menyimpan nilai harfiah None di cache, karena anda tidak akan dapat membedakan diantara nilai None disimpan anda dan kehilangan sebuah cache ditunjukkan oleh nilai kembalian dari None.

cache.get() dapat mengambil sebuah argumen default. Ini menentukan nilai mana untuk dikembalikan jika obyek tidak ada di cache:

>>> cache.get('my_key', 'has expired')
'has expired'
cache.add(key, value, timeout=DEFAULT_TIMEOUT, version=None)

Untuk 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')
>>> cache.add('add_key', 'New value')
>>> cache.get('add_key')
'Initial value'

Jika 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.

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

Jika anda ingin mendapatkan nilai kunci atau sekumpulan nilai jika kunci tidak di cache, ada metode get_or_set(). Itu mengambil parameter sama seperti get() tetapi awalan disetel sebagai nilai cache baru untuk kunci itu, daripada hanya dikembalikan:

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

Anda dapat juga melewatkan callable apapun sebagai nilai awalan:

>>> import datetime
>>> cache.get_or_set('some-timestamp-key', datetime.datetime.now)
datetime.datetime(2014, 12, 11, 0, 15, 49, 457920)
cache.get_many(keys, version=None)

Ada 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)
>>> cache.set('b', 2)
>>> cache.set('c', 3)
>>> cache.get_many(['a', 'b', 'c'])
{'a': 1, 'b': 2, 'c': 3}
cache.set_many(dict, timeout)

Untuk 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})
>>> cache.get_many(['a', 'b', 'c'])
{'a': 1, 'b': 2, 'c': 3}

Seperti cache.set(), set_many() mengambil sebuah pilihan parameter timeout.

Pada backend didukung (memcached), set_many() megnembalikan sebuah daftar dari kunci-kunci yang gagal dimasukkan.

Changed in Django 2.0:

Nilai kembalian mengandung daftar dari kunci-kunci gagal telah ditambahkan.

cache.delete(key, version=None)

Anda dapat menghapus kunci-kunci dengan jelas dengan delete(). Ini adalah cara mudah dari membersihkan cache untuk obyek tertentu:

>>> cache.delete('a')
cache.delete_many(keys, version=None)

Jika anda ingin membersihkan seikat kunci sekaligus, delete_many() dapat mengambil sebuah daftar dari kunci untuk dibersihkan:

>>> cache.delete_many(['a', 'b', 'c'])
cache.clear()

Akhirnya, 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()
cache.touch(key, timeout=DEFAULT_TIMEOUT, version=None)
New in Django 2.1:

cache.touch() mensetel kadaluarsa baru untuk sebuah kunci. Sebagai contoh, untuk memperbaharui sebuah kunci untuk kadaluarsa 10 detik dari sekarang:

>>> cache.touch('a', 10)
True

Like other methods, the timeout argument is optional and defaults to the TIMEOUT option of the appropriate backend in the CACHES setting.

touch() mengembalikan True jika kunci berhasil disentuh, False sebaliknya.

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

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)
>>> cache.incr('num')
2
>>> cache.incr('num', 10)
12
>>> cache.decr('num')
11
>>> cache.decr('num', 5)
6

Catatan

Metide incr()/decr() tidak menjamin menjadi atom, Pada backend itu yang mendukung penaikan/penurunan atom (kebanyakan terutama backend memcache), penaikan dan penurunan akan menjadi atom. Bagaimanapun, jika backend tidak asli menyediakan sebuah tindakan penaikan/penurunan, itu akan diterapkan menggunakan dua-langkah mengambil/memperbaharui.

cache.close()

Anda dapat menutup hubungan ke cache anda dengan close() jika diterapkan oleh backend cache.

>>> cache.close()

Catatan

Untuk cache yang tidak menerapkan metode close itu adalah no-op.

Awalan kunci cache

Jika 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.

Untuk 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.

Memversikan 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.

Django 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
>>> cache.set('my_key', 'hello world!', version=2)
>>> # Get the default version (assuming version=1)
>>> cache.get('my_key')
None
>>> # Get version 2 of the same key
>>> cache.get('my_key', version=2)
'hello world!'

Versi 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'
>>> cache.incr_version('my_key')
>>> # The default version still isn't available
>>> cache.get('my_key')
None
# Version 2 isn't available, either
>>> cache.get('my_key', version=2)
None
>>> # But version 3 *is* available
>>> cache.get('my_key', version=3)
'hello world!'

Perubahan kunci cache

Seperti 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:

def make_key(key, key_prefix, version):
    return ':'.join([key_prefix, str(version), key])

Jika 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.

Pengaturan 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.

Peringatan kunci cache

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

from django.core.cache import CacheKeyWarning

warnings.simplefilter("ignore", CacheKeyWarning)

Jika 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

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

...dan menggunakan jalur Python bertitik pada kelas ini di bagain BACKEND dari pengaturan CACHES.

Cache hilir

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.

Ini adalah sedikit contoh dari cache hilir:

  • ISP 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.

Sebagai contoh, katakan anda mengoperasikan sistem surel jaringan, dan isi dari halaman "inbox" dengan jelas bergantung pada pengguna mana masuk. Jika sebuah ISP membabi buta cache situs anda, kemudian pengguna eprtama yang masuk melalui ISP itu akan mempunyai halaman inbox pengguna-tertentu mereka cache untuk pengguna berikutnya pada situs. Itu tidak keren.

Untungnya, 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.

Menggunakan kepala Vary

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

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

Di kasus ini, mekanisme cache (seperti middleware cache sendiri Django) akan cache sebuah versi terpisah dari halaman untuk setiap agen-pengguna unik.

Keuntungan 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')
def my_view(request):
    ...

Ini 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
def my_view(request):
    ...

@vary_on_headers('Cookie')
def my_view(request):
    ...

Kepala 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
from django.utils.cache import patch_vary_headers

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

patch_vary_headers 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.

Mengendalikan tembolok: Menggunakan kepala lainnya

Masalah lain dengan cache adalah pribadi dari data dan pertanyaan dari dimana data harus disimpan di cache urutan kebawah.

Seorang 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.

Pemecahannya 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

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

Penghias ini merawat dari mengirim keluar kepala HTTP sesuai dibelakang layar.

Catat 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
from django.views.decorators.vary import vary_on_cookie

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

    return response

Anda 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:

from django.views.decorators.cache import cache_control

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

(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

Daftar penuh dari arahan dikenal dapat ditemukan di IANA registry (catat bahwa tidak semua dari mereka memberlakukan terhadap tanggapan).

Jika 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

@never_cache
def myview(request):
    ...

urutan dari MIDDLEWARE

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.

Back to Top