動的なウェブサイトの基本的なトレードオフは、ええと、それが動的であるということです。ユーザーがページをリクエストするたびに、ウェブサーバーはあらゆる種類の計算を行い (データベースのクエリから、テンプレートのレンダリングやビジネスロジックの実行まで)、サイトの訪問者が目にするページを作成します。これは、処理オーバーヘッドの観点から、ファイルシステムからファイルを読み取る標準的なサーバー構成よりもはるかに高コストです。
\nほとんどの Web アプリケーションでは、このオーバーヘッドは大した問題ではありません。ほとんどの Web アプリケーションは washingtonpost.com や slashdot.org ではなく、そこそこのトラフィックがある小規模から中規模のサイトです。ただし、中トラフィックから高トラフィックのサイトでは、オーバーヘッドをできる限り削減することが不可欠です。
そこで登場するのがキャッシュです。
\n何かをキャッシュすることは、次回に計算を実行する必要がないように、高価な計算の結果を保存することです。以下に示すのは、動的に生成された Web ページでキャッシュがどのように機能するかを説明する疑似コードです。
\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 には、動的ページを保存できるロバストなキャッシュ システムが付属しているため、各リクエストごとに動的ページを計算する必要はありません。便宜上、Django は異なるレベルのキャッシュ粒度を提供しています。特定のビューの出力をキャッシュしたり、生成が難しい部分のみをキャッシュしたり、サイト全体をキャッシュできます。
\nDjango は、 Squid やブラウザベースのキャッシュなどの「ダウンストリーム」キャッシュでもうまく機能します。これらは、直接コントロールできないタイプのキャッシュですが、サイトのどの部分をどのようにキャッシュする必要があるかというヒントを (HTTP ヘッダー経由で) 提供できます。
\n\nキャッシュシステムにはちょっとした設定が必要です。つまり、キャッシュされたデータをどこに置くか、データベースか、ファイルシステムか、メモリに直接置くかを指定しなければなりません。これはキャッシュのパフォーマンスに影響する重要な決定です。
\nキャッシュの設定は設定ファイルの CACHES 設定にあります。ここでは、 CACHES で使用可能なすべての値について説明します。
Memcached は完全にメモリベースのキャッシュ・サーバで、元々はLiveJournal.comの高負荷を処理するために開発され、その後Danga Interactiveによってオープンソース化されました。FacebookやWikipediaなどのサイトで使用され、データベースへのアクセスを減らし、サイトのパフォーマンスを劇的に向上させます。
\nMemcached はデーモンとして動作し、指定された量の RAM が割り当てられます。キャッシュにデータを追加、取得、削除するための高速なインターフェイスを提供するだけです。すべてのデータはメモリに直接保存されるので、データベースやファイルシステムの使用によるオーバーヘッドはありません。
\nMemcached 自体をインストールした後、Memcached バインディングをインストールする 必要があります。Python の Memcached バインディングはいくつかありますが、 Django がサポートしているのは pylibmc と pymemcache です。
\nDjango で Memcached を使用する
\nBACKEND を django.core.cache.backends.memcached.PyMemcacheCache または django.core.cache.backends.memcached.PyLibMCCache (選択した memcached バインディングによる) に設定する
LOCATION を ip:port の値 (ここで、ip は Memcached デーモンの IP アドレス、port は Memcached が起動しているポート)、または、unix:path の値に設定する (ここで、path は Memcached Unix socket ファイルへのパス)。
次の例では、Memcached は localhost (127.0.0.1) port 11211 で起動していて、pymemcache バインディングを使用しています。
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",\n "LOCATION": "127.0.0.1:11211",\n }\n}\n次の例では、Memcached はローカルの Unix socket ファイル /tmp/memcached.sock 経由で利用可能であり、pymemcache バインディングを使用しています。
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.memcached.PyMemcacheCache",\n "LOCATION": "unix:/tmp/memcached.sock",\n }\n}\nMemcached の優れた機能の一つは、複数のサーバでキャッシュを共有できることです。つまり、複数のマシンで Memcached デーモンを実行することができ、各マシンでキャッシュの値を重複させることなく、 単一の キャッシュとして扱うことができます。この機能を利用するには、全てのサーバのアドレスを LOCATION に、セミコロンまたはカンマ区切りの文字列、あるいはリストとして記述します。
このインスタンスでは、IP アドレス 172.19.26.240 と 172.19.26.242 で動作する Memcached インスタンスをポート 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}\n以下の例では、172.19.26.240 (port 11211)、172.19.26.242 (port 11212)、172.19.26.244 (port 11213) の IP アドレスで動作する Memcached インスタンスでキャッシュを共有しています:
\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}\nデフォルトでは、 PyMemcacheCache バックエンドは以下のオプションを設定します( OPTIONS で上書きできます):
"OPTIONS": {\n "allow_unicode_keys": True,\n "default_noreply": False,\n "serde": pymemcache.serde.pickle_serde,\n}\nMemcachedについての最後のポイントは、メモリベースのキャッシュには欠点があるということです。キャッシュされたデータはメモリに保存されるので、サーバーがクラッシュするとデータは失われます。メモリは永続的なデータ保存用ではないので、メモリベースのキャッシュを唯一のデータ保存用として使わないようにしましょう。明らかに、 Django のキャッシュバックエンドはどれも、永続的な保存には使うべきではありません。これらは全てキャッシュのためのソリューションであって、ストレージではありません。しかし、メモリベースのキャッシュは特に一時的なものであるため、 ここでに記載しておきます。
\nRedis は、キャッシュに利用できるインメモリ データベースです。はじめに、Redis サーバーがローカルまたはリモートマシン上で起動している必要があります。
\nRedis サーバを設定した後、Redis の Python バインディングをインストールする必要があります。 redis-py は Django によってネイティブにサポートされているバインディングです。 hiredis-py パッケージも推奨のひとつです。
\nRedis をキャッシュ バックエンドとして Django で使用するには、次のようにします。
\nBACKEND を django.core.cache.backends.redis.RedisCache に設定する。
LOCATION を、適切なスキーマを使用して Redis インスタンスを指す URL に設定する。利用可能なスキーマの詳細 については、redis-py のドキュメントを参照してください。
たとえば、Redis が 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}\nRedis サーバーは認証で保護されていることがよくあります。ユーザー名とパスワードを提供するには、LOCATION 内に URL とともに追加します。
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.redis.RedisCache",\n "LOCATION": "redis://username:password@127.0.0.1:6379",\n }\n}\nレプリケーション・モードで複数のRedisサーバーを設定している場合は、セミコロンまたはカンマ区切りの文字列、あるいはリストとしてサーバーを指定できます。複数のサーバーを使用している場合、書き込み操作は最初のサーバー（リーダー）で実行されます。読み取り操作は、ランダムに選ばれた他のサーバ（レプリカ）で実行されます:
\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 はキャッシュデータをデータベース中に保存できます。この仕組みは、高速で適切にインデックス付けされたデータベースサーバーがある場合に、有効に機能します。
\nデータベースのテーブルをキャッシュのバックエンドに使用する場合には、以下のように設定します。
\nBACKEND を django.core.cache.backends.db.DatabaseCache に設定する
LOCATION の tablename にデータベーステーブルの名前を設定します。この名前は、データベースで未使用かつ有効な名前であれば、自分が好きな名前で構いません。
この例では、キャッシュテーブルの名前を my_cache_table と設定しています。
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.db.DatabaseCache",\n "LOCATION": "my_cache_table",\n }\n}\n他のキャッシュバックエンドとは異なり、データベースキャッシュはデータベースレベルでの期限切れエントリの自動間引き (culling) をサポートしていません。その代わり、 add() や set() 、 touch() が呼び出されるたびに、期限切れのキャッシュエントリが「間引き」されます。
データベース キャッシュを使用する前に、次のコマンドでキャッシュテーブルを必ず作成する必要があります。
\npython manage.py createcachetable\nこのコマンドにより、データベース内に1つのテーブルが作成され、Django のデータベースキャッシュシステムに必要な適切なフォーマットが生成されます。テーブルの名前は LOCATION が使用されます。
複数のデータベースキャッシュが使用される場合、createcachetable は1つのキャッシュごとに、対応する1つのテーブルを作成します。
複数のデータベースを使用する場合、createcachetable は、データベースのルートの allow_migrate() メソッド (以下を参照) を監視します。
migrate と同様に、createcachetable は既に存在する既存のテーブルにたいしては手を触れません。存在しないテーブルのみを生成します。
実行される予定の SQL を実行せずに表示するためには、createcachetable --dry-run オプションを使用します。
複数のデータベースでデータベースキャッシュを使用する場合、データベースキャッシュテーブルのためにルーティングの指示も設定する必要があります。ルーティングの目的で、データベースキャッシュテーブルは、django_cache という名前のアプリケーションに CacheEntry という名前のモデルとして表示されます。このモデルはモデルキャッシュには表示されませんが、ルーティングの目的でモデルの詳細情報を使用できます。
たとえば、以下のルーターはすべてのキャッシュの読み込み操作を cache_replica に転送し、すべての書き込み操作を cache_primary に転送します。キャッシュテーブルは 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\nデータベースキャッシュモデルに対してルーティングの方向を指定しなかった場合、キャッシュバックエンドは default データベースを使用します。
そして、データベースキャッシュバックエンドを使用しなかった場合には、データベースキャッシュモデルに対してデータベースルーティングの指示を提供することについて心配する必要はありません。
\nファイルベースのバックエンドは、各キャッシュの値を独立したファイルとしてシリアライズして保存します。このバックエンドを使用するには、BACKEND を "django.core.cache.backends.filebased.FileBasedCache" に設定して、LOCATION を適切なディレクトリに設定します。たとえば、キャッシュデータを /var/tmp/django_cache に保存するには、次の設定を使ってください。
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",\n "LOCATION": "/var/tmp/django_cache",\n }\n}\nWindows では、次のようにドライブ文字をパスの最初に付けてください。
\nCACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.filebased.FileBasedCache",\n "LOCATION": "c:/foo/bar",\n }\n}\nディレクトリのパスは絶対パスである必要があります。つまり、ファイルシステムのルートから始まる必要があります。設定の最後にスラッシュを置くかどうかは関係ありません。
\nこの設定が指すディレクトリは、存在して読み込みと書き込みが可能であるか、または、ウェブサーバーを実行しているシステムユーザーによって作成可能であることを確認してください。上の例を続けると、もしサーバーが apache ユーザーで実行されているなら、/var/tmp/django_cache が存在して apache ユーザーにより読み書き可能であるか、このディレクトリを apache ユーザーが作成できることを確認してください。
設定ファイルに他のキャッシュが指定されていない場合、これがデフォルトのキャッシュとなります。インメモリキャッシュの速度の利点が欲しいが、Memcached を扱うのが難しい場合は、 ローカルメモリキャッシュバックエンドを検討してください。このキャッシュはプロセス単位 (後述) で、スレッドセーフです。これを使うには、 BACKEND を "django.core.cache.backends.locmem.LocMemCache" に設定します。たとえば
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.locmem.LocMemCache",\n "LOCATION": "unique-snowflake",\n }\n}\nキャッシュの LOCATION は個々のメモリストアを識別するために使用されます。もし locmem キャッシュが1つしかない場合は LOCATION を省略できます。しかし、複数のローカルメモリーキャッシュがある場合は、それらを区別するために少なくとも1つに名前を割り当てる必要があります。
キャッシュは LRU (least-recently-used) 淘汰戦略 (culling strategy) を使用します。
\n各プロセスはそれ自身のプライベートキャッシュインスタンスを持つことに注意してください。このことは、ローカル・メモリ・キャッシュが特にメモリ効率に優れているわけではないことを意味します。そのため、おそらく本番環境には良い選択ではありません。開発環境には適しています。
\n最後に、 Django には実際にはキャッシュしない「ダミー」キャッシュが付属しています。何もせずにキャッシュインターフェースを実装しているだけです。
\nこれは、様々な場所で重量級のキャッシュを使用する本番サイトと、開発/テスト用に、キャッシュを行わず、コード変更も最小限に留めたい環境がある場合に便利です。ダミーキャッシュをアクティブにするには、BACKEND を以下のように設定します。
CACHES = {\n "default": {\n "BACKEND": "django.core.cache.backends.dummy.DummyCache",\n }\n}\nDjango は「箱から出してすぐに」多くのキャッシュバックエンドをサポートしていますが、カスタマイズ したキャッシュバックエンドを使いたいこともあるでしょう。Django で外部のキャッシュバックエンドを使用するには、下記のように、 CACHES 設定の BACKEND に Python のインポートパスを使用します:
CACHES = {\n "default": {\n "BACKEND": "path.to.backend",\n }\n}\n独自のバックエンドを構築する場合は、標準のキャッシュバックエンドをリファレンス実装として使うことができます。コードは Django ソースの django/core/cache/backends/ ディレクトリにあります。
\n注記：ホストがサポートしていないなど、やむを得ない理由がない限り、Django に付属しているキャッシュバックエンドを使用するべきです。それらは十分にテストされており、よくドキュメント化されています。
\nそれぞれのキャッシュバックエンドはキャッシュの動作を制御するために追加の引数を指定できます。これらの引数は CACHES 設定の追加キーとして提供されます。有効な引数は以下の通りです:
TIMEOUT: キャッシュに使用するデフォルトのタイムアウトを秒単位で指定します。この引数のデフォルトは 300 秒（5分）です。 TIMEOUT に None を指定することで、デフォルトではキャッシュキーの有効期限が切れません。値を 0 にすると、キーはすぐに期限切れになります（事実上 "キャッシュしない"）。
OPTIONS: キャッシュバックエンドに渡すオプション。有効なオプションのリストはバックエンドによって異なり、サードパーティライブラリにバックされたキャッシュバックエンドはそのオプションを直接キャッシュライブラリに渡します。
独自の淘汰戦略 (culling strategy) を実装しているキャッシュバックエンド (locmem、filesystem、database バックエンド) では、以下のオプションが有効です:
MAX_ENTRIES: 古い値が削除されるまでにキャッシュに保存できる最大エントリ数。この引数のデフォルトは 300 です。
CULL_FREQUENCY: MAX_ENTRIES に達したときに間引き (cull) されるエントリの割合。実際の割合は 1 / CULL_FREQUENCY なので、 CULL_FREQUENCY を 2 に設定すると、 MAX_ENTRIES に達したときにエントリの半分をカリングします。この引数は整数で、デフォルトは 3 です。
CULL_FREQUENCY に 0 という値を指定すると、 MAX_ENTRIES に達したときにキャッシュ全体がダンプされます。一部のバックエンド (特に database) では、キャッシュミスが増える代わりにカリング（間引き）が非常に速くなります。
Memcached と Redis のバックエンドは、クライアントの動作をより高度に制御できるように、クライアントのコンストラクタにキーワード引数として OPTIONS の内容を渡します。使用例は以下を参照してください。
KEY_PREFIX: Django サーバが使用する全てのキャッシュキーに自動的に含まれる文字列です（デフォルトでは先頭に付加されます）。
詳細は キャッシュのドキュメント を参照してください。
\nVERSION: Django サーバが生成するキャッシュキーのデフォルトのバージョン番号。
詳細は キャッシュのドキュメント を参照してください。
\nKEY_FUNCTION プレフィックス、バージョン、およびキーを最終的なキャッシュ・キーに合成する方法を定義する関数へのドット区切りパスを含む文字列。
詳細は キャッシュのドキュメント を参照してください。
\nこの例では、ファイルシステム・バックエンドをタイムアウト60秒、最大容量1000アイテムで設定しています。
\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}\n以下は、pylibmc ベースのバックエンドをバイナリプロトコル、SASL認証、および 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}\n以下は pymemcache ベースのバックエンドの設定例です。クライアントのプーリングを有効にし (クライアントの接続を維持することでパフォーマンスを向上させることができます)、memcache/ネットワークのエラーをキャッシュミスとして扱い、接続ソケットに TCP_NODELAY フラグを設定します。
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}\n以下は、redis ベースのバックエンドの設定例です。データベースに 10 を選択し (デフォルトではRedisには16の論理データベースがあります) 、 parser class を指定し (hiredis-py パッケージがインストールされている場合、デフォルトで redis.connection.HiredisParser が使用されます)、およびカスタムの connection pool class を設定しています (デフォルトでは redis.ConnectionPool が使用されます)。
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 "parser_class": "redis.connection.PythonParser",\n "pool_class": "redis.BlockingConnectionPool",\n },\n }\n}\nキャッシュを設定したら、キャッシュを使う最も簡単な方法はサイト全体をキャッシュすることです。この例のように、 'django.middleware.cache.UpdateCacheMiddleware' と 'django.middleware.cache.FetchFromCacheMiddleware' を MIDDLEWARE 設定に追加する必要があります:
MIDDLEWARE = [\n "django.middleware.cache.UpdateCacheMiddleware",\n "django.middleware.common.CommonMiddleware",\n "django.middleware.cache.FetchFromCacheMiddleware",\n]\n次に、以下の必要な設定を Django 設定ファイルに追加します:
\nCACHE_MIDDLEWARE_ALIAS -- ストレージに使用するキャッシュのエイリアス。
CACHE_MIDDLEWARE_SECONDS -- 各ページがキャッシュされるべき秒数を整数で指定します。
CACHE_MIDDLEWARE_KEY_PREFIX -- キャッシュが同じ Django インストールを使っている複数のサイトで共有され ている場合、キーの衝突を防ぐために、サイトの名前か、この Django インスタンスに固有な文字列を指定します。気にしないなら空文字列を使いましょう。
FetchFromCacheMiddleware はリクエストヘッダとレスポンスヘッダが許す限り、ステータス 200 の GET と HEAD レスポンスをキャッシュします。異なるクエリパラメータを持つ同じURLへのリクエストに対するレスポンスはユニークなページとみなされ、別々にキャッシュされます。このミドルウェアは、HEADリクエストが、対応するGETリクエストと同じレスポンスヘッダーで応答されることを期待します。その場合、HEADリクエストに対してキャッシュされたGETレスポンスを返すことができます。
さらに、UpdateCacheMiddleware は ダウンストリームキャッシュ に影響を与えるいくつかのヘッダを HttpResponse に自動的に設定します:
Expires ヘッダーに現在の日時と定義された CACHE_MIDDLEWARE_SECONDS をセットします。
Cache-Control ヘッダにページの最大寿命をセットします -- ここでも CACHE_MIDDLEWARE_SECONDS 設定を使用します。
ミドルウェアについては ミドルウェア (Middleware) を参照してください。
\nビューがキャッシュの有効期限を設定している場合 (つまり、ヘッダの Cache-Control に max-age セクションがある場合) は、 CACHE_MIDDLEWARE_SECONDS ではなく、有効期限までページがキャッシュされます。django.views.decorators.cache のデコレータを使用すると、ビューの有効期限を簡単に設定 (cache_control() デコレータを使用) したり、ビューのキャッシュを無効にしたり (never_cache() デコレータを使用) することができます。これらのデコレータについての詳細は、 他のヘッダを使用する セクションを参照してください。
USE_I18N が True に設定されている場合、生成されたキャッシュキーにアクティブな 言語 の名前が含まれるようになります。 Django はどうやって言語の優先順位を検出するのか？ も参照してください。これにより、自分でキャッシュキーを作成する必要なく、複数言語のサイトを簡単にキャッシュできるようになります。
USE_TZ が True に設定されている場合、キャッシュキーには カレントタイムゾーン も含まれます。
キャッシュフレームワークをより細かい単位で使用するには、個別のビューの出力をキャッシュする方法があります。django.views.decorators.cache は cache_page デコレーターを定義しており、これを使うとビューのレスポンスが自動的にキャッシュされるようになります。
from django.views.decorators.cache import cache_page\n\n\n@cache_page(60 * 15)\ndef my_view(request): ...\ncache_page はキャッシュのタイムアウトを秒数で指定する1つの引数を取ります。上の例では、my_view() ビューの結果が15分間キャッシュされます。(ここでリーダビリティのために 60 * 15 と書いていることに注意してください。60 * 15 は 900 つまり15分×60秒と評価されます。)
cache_page で設定されたキャッシュのタイムアウトは、Cache-Control ヘッダの max-age ディレクティブよりも優先されます。
サイトごとのキャッシュと同様に、ビューごとのキャッシュは URL でキーが区別されます。もし複数の URL が同じビューを指した場合、各 URL が別にキャッシュされます。my_view の例を続けて、URLconf が次のようになっているとします。
urlpatterns = [\n path("foo/<int:code>/", my_view),\n]\nこのとき、/foo/1/ と /foo/23/ へのリクエストは別々にキャッシュされます。しかし、特定の URL (たとえば、/foo/23/) が一度リクエストされると、その URL への続くリクエストにはキャッシュが使われます。
cache_page はオプション引数の cache を取ることもできます。これを使うと、ビューの結果をキャッシュするときに、デコレータに (CACHES 設定から) 特定のキャッシュを使うように指示できます。デフォルトでは、default キャッシュが使われますが、使いたいキャッシュはどれでも指定できます。
@cache_page(60 * 15, cache="special_cache")\ndef my_view(request): ...\nまた、ビューごとにキャッシュプレフィックスを上書きすることもできます。 cache_page はオプションのキーワード引数 key_prefix を取ります。これはミドルウェアの CACHE_MIDDLEWARE_KEY_PREFIX 設定と同じように動作します。 次のように使用します:
@cache_page(60 * 15, key_prefix="site1")\ndef my_view(request): ...\nkey_prefix 引数と cache 引数は同時に指定できます。 key_prefix 引数と CACHES で指定した KEY_PREFIX は連結されます。
さらに、 cache_page は自動的にレスポンスに Cache-Control と Expires ヘッダを設定します。このヘッダは ダウンストリームキャッシュ に影響を与えます。
前のセクションの例では、 cache_page が my_view 関数を変更するため、ビューがキャッシュされることをハードコードしていました。この方法では、ビューをキャッシュシステムに結合することになり、いくつかの理由から理想的ではありません。例えば、キャッシュのない別のサイトでビュー関数を再利用したい場合や、キャッシュされずにビューを使いたい人にビューを配布したい場合などです。このような問題の解決策は、ビュー関数そのものではなく URLconf でビューごとのキャッシュを指定することです。
URLconf でビュー関数を参照するときに cache_page でラップすることで、これを実現できます。以下は以前の古い URLconf です。
urlpatterns = [\n path("foo/<int:code>/", my_view),\n]\n以下は my_view を cache_page でラップしたものです。
from django.views.decorators.cache import cache_page\n\nurlpatterns = [\n path("foo/<int:code>/", cache_page(60 * 15)(my_view)),\n]\nさらにコントロールしたい場合は、 cache テンプレートタグを使ってテンプレートの断片をキャッシュすることもできます。テンプレートからこのタグにアクセスするには、テンプレートの先頭付近に {% load cache %} を記述します。
テンプレートタグ {% cache %} は指定した時間だけブロックの内容をキャッシュします。少なくとも2つの引数を取ります。秒単位のキャッシュタイムアウトと、キャッシュフラグメントに与える名前です。timeout が None の場合、フラグメントは永遠にキャッシュされます。名前はそのまま使用されるので、変数は使えません。次に例を示します。
{% load cache %}\n{% cache 500 sidebar %}\n .. sidebar ..\n{% endcache %}\nフラグメントの内部に現れる動的なデータに応じて、フラグメントの複数のコピーをキャッシュしたい場合があります。たとえば、先ほどの例で使用したサイドバーを、サイトのすべてのユーザーに対して個別にキャッシュしたいとします。これを行うには、キャッシュフラグメントを一意に識別するために、フィルタの有無にかかわらず、1つ以上の追加の引数を {% cache %} テンプレートタグに渡します。
{% load cache %}\n{% cache 500 sidebar request.user.username %}\n .. sidebar for logged in user ..\n{% endcache %}\nUSE_I18N が True に設定されている場合、サイトごとのミドルウェアキャッシュは アクティブな言語 を尊重します。テンプレートタグの cache では 翻訳固有の変数 を使えば同じ結果が得られます:
{% 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 %}\nテンプレート変数が整数値に解決されるなら、キャッシュタイムアウトにはテンプレート変数が使えます。例えば、テンプレート変数 my_timeout が値 600 に指定されている場合、以下の2つの例は等価です:
{% cache 600 sidebar %} ... {% endcache %}\n{% cache my_timeout sidebar %} ... {% endcache %}\nこの機能はテンプレート内での繰り返しを避けるのに便利です。1つの変数にタイムアウトを指定し、その値を再利用できます。
\nデフォルトでは、キャッシュタグは "template_fragments" というキャッシュを使用しようとします。そのようなキャッシュが存在しない場合は、デフォルトのキャッシュを使用します。キーワード引数 using で、使用する別のキャッシュバックエンドを選択できます。
{% cache 300 local-thing ... using="localcache" %}\n設定されていないキャッシュ名を指定することはエラーとみなされます。
\nキャッシュされたフラグメントに使用されるキャッシュキーを取得したい場合は、 make_template_fragment_key を使用します。フラグメント名 fragment_name は cache テンプレートタグの2番目の引数と同じです。この関数は、キャッシュされたアイテムを無効にしたり上書きしたりする場合などに便利です:
>>> 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\nレンダリングされたページ全体をキャッシュしてもあまりメリットがないこともありますし、実際、過剰なキャッシュはかえって不便です。
\nたとえば、あなたのサイトには、結果が複数の高コストなクエリに依存し、その結果が異なる間隔で変化するビューが含まれているとします。この場合、サイト単位やビュー単位のキャッシュ戦略が提供するフルページキャッシュを使うのは理想的ではありません。なぜなら、結果全体をキャッシュしたいとは思わないでしょうが(データの一部が頻繁に変更されるからです)、めったに変更されない結果はキャッシュしたいからです。
\nこのような場合のために、 Django は低レベルのキャッシュ API を公開しています。この API を使えば、好きなレベルでオブジェクトをキャッシュに保存できます。 安全に pickle 化できる Python オブジェクトなら何でもキャッシュできます: 文字列、辞書、モデルオブジェクトのリストなど。(ほとんどの一般的なPythonオブジェクトはpickle化できます。pickle化についての詳細はPythonのドキュメントを参照してください)。
\nCACHES 設定で設定したキャッシュには、 django.core.cache.caches という Dict のようなオブジェクトでアクセスできます。同じスレッドで同じエイリアスを繰り返しリクエストすると、同じオブジェクトが返されます。
>>> from django.core.cache import caches\n>>> cache1 = caches["myalias"]\n>>> cache2 = caches["myalias"]\n>>> cache1 is cache2\nTrue\n指定したキーが存在しない場合、 InvalidCacheBackendError が発生します。
スレッドセーフを実現するために、キャッシュバックエンドの異なるインスタンスがスレッドごとに返されます。
\nショートカットとして、デフォルトのキャッシュは django.core.cache.cache で利用できます:
>>> from django.core.cache import cache\nこのオブジェクトは caches['default'] と等価です。
基本的なインターフェイスは、次のようになります。
\n>>> cache.set("my_key", "hello, world!", 30)\n>>> cache.get("my_key")\n'hello, world!'\nkey には str を指定し、 value には任意の Python オブジェクトを指定します。
引数の timeout はオプションで、デフォルトは CACHES 設定 (上記で説明) にある適切なバックエンドの timeout 引数です。これはキャッシュに保存される秒数です。 timeout に None を渡すと、値は永遠にキャッシュされます。 timeout に 0 を渡すと、値はキャッシュされません。
オブジェクトがキャッシュに存在しない場合、 cache.get() は None を返します:
>>> # Wait 30 seconds for 'my_key' to expire...\n>>> cache.get("my_key")\nNone\nオブジェクトがキャッシュに存在するかどうかを判断する必要があり、リテラル値 None を保存した場合は、デフォルトとして sentinel オブジェクトを使用します:
>>> 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() は default 引数を取ることができます。これは、オブジェクトがキャッシュに存在しない場合に返す値を指定します:
>>> cache.get("my_key", "has expired")\n'has expired'\nキーがまだ存在しない場合にのみキーを追加するには、 add() メソッドを使用します。このメソッドは set() と同じパラメータを受け取りますが、指定したキーがすでに存在する場合はキャッシュを更新しようとしません:
>>> cache.set("add_key", "Initial value")\n>>> cache.add("add_key", "New value")\n>>> cache.get("add_key")\n'Initial value'\nもし add() が値をキャッシュに保存したかどうかを知りたい場合は、戻り値をチェックできます。値が保存されていれば True を返し、そうでなければ False を返します。
キーの値を取得したり、そのキーがキャッシュにない場合に値を設定したい場合は、 get_or_set() メソッドが使えます。これは get() と同じパラメータを受け取りますが、そのキーのデフォルトの戻り値が設定されます:
>>> cache.get("my_new_key") # returns None\n>>> cache.get_or_set("my_new_key", "my new value", 100)\n'my new value'\nまた、任意の呼び出し可能オブジェクトを デフォルト 値として渡すこともできます:
\n>>> import datetime\n>>> cache.get_or_set("some-timestamp-key", datetime.datetime.now)\ndatetime.datetime(2014, 12, 11, 0, 15, 49, 457920)\n一度だけキャッシュをヒットする get_many() インターフェースもあります。 get_many() は、キャッシュに実際に存在する (そして有効期限が切れていない) キーをすべて含む辞書を返します:
>>> 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}\nより効率的に複数の値を指定するには、 set_many() を使用してキーと値のペアの辞書を渡します:
>>> cache.set_many({"a": 1, "b": 2, "c": 3})\n>>> cache.get_many(["a", "b", "c"])\n{'a': 1, 'b': 2, 'c': 3}\ncache.set() と同様に、 set_many() はオプションの timeout パラメータを受け取ります。
サポートされているバックエンド (memcached) では、 set_many() は挿入に失敗したキーのリストを返します。
delete() で明示的にキーを削除することで、特定のオブジェクトのキャッシュをクリアできます:
>>> cache.delete("a")\nTrue\ndelete() はキーの削除に成功すると True を返し、失敗すると False を返します。
一度にたくさんのキーをクリアしたい場合は、 delete_many() にクリアしたいキーのリストを渡します:
>>> cache.delete_many(["a", "b", "c"])\n最後に、キャッシュ内のすべてのキーを削除したい場合は cache.clear() を使用します。 clear() はアプリケーションによって設定されたキーだけでなく、 すべての キーをキャッシュから削除します:
>>> cache.clear()\ncache.touch() はキーの有効期限を設定します。例えば、キーの有効期限を10秒後に更新する場合:
>>> cache.touch("a", 10)\nTrue\n他のメソッドと同様に、 timeout 引数はオプションで、デフォルトは CACHES 設定の適切なバックエンドの TIMEOUT オプションです。
touch() はキーが正しく touch された場合は True を返し、そうでない場合は False を返します。
incr() メソッドまたは decr() メソッドを使用して、既に存在するキーをインクリメント/デクリメントすることもできます。デフォルトでは、既存のキャッシュの値が 1 だけインクリメント/デクリメントされます。インクリメント/デクリメントの呼び出しに引数を指定することで、1以外のインクリメント/デクリメント値を指定できます。存在しないキャッシュ・キーをインクリメントまたはデクリメントしようとすると、ValueError が発生します:
>>> 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\nキャッシュバックエンドに実装されていれば、 close() でキャッシュへの接続を閉じることができます。
>>> cache.close()\nサーバ間でキャッシュインスタンスを共有している場合、あるいは本番環境と開発環境の間でキャッシュインスタンスを共有している場合、あるサーバでキャッシュされたデータが別のサーバで使用される可能性があります。キャッシュされたデータのフォーマットがサーバ間で異なる場合、非常に診断が難しい問題につながる可能性があります。
\nこれを防ぐために、 Django はサーバが使う全てのキャッシュキーの前にプレフィックスを付ける機能を提供します。特定のキャッシュキーが保存または取得されると、 Django は自動的に KEY_PREFIX キャッシュ設定の値をキャッシュキーの先頭に付加します。
各 Django インスタンスに異なる KEY_PREFIX を持たせることで、キャッシュ値が衝突しないようにできます。
キャッシュされた値を使用する実行中のコードを変更する場合、既存のキャッシュされた値を消去する必要があるかもしれません。これを行う最も簡単な方法はキャッシュ全体を削除することですが、まだ有効で有用なキャッシュ値を失うことになります。
\nDjango は個々のキャッシュ値をターゲットにする、より良い方法を提供します。Django のキャッシュフレームワークには、 VERSION キャッシュ設定で指定できる、システム全体のバージョン識別子があります。この設定の値は、自動的にキャッシュ・プレフィックスとユーザが指定したキャッシュ・キーと組み合わされ、最終的なキャッシュ・キーが得られます。
デフォルトでは、どのようなキャッシュキーのリクエストも自動的にサイトのデフォルトのキャッシュキーのバージョンを含みます。しかし、基本的なキャッシュ関数には version 引数が含まれているので、特定のキャッシュキーのバージョンを指定できます。たとえば:
>>> # 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!'\n特定のキーのバージョンは incr_version() メソッドと decr_version() メソッドで増減できます。これにより、特定のキーのバージョンを新しいものに変更できます。先ほどの例の続きで、下記のようにします:
>>> # 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!'\n前の2つのセクションで説明したように、ユーザから提供されたキャッシュ・キーはそのまま使用されるわけではありません。このキーは、キャッシュ・プレフィックスおよびキーバージョンと組み合わされて最終的なキャッシュ・キーとなります。デフォルトでは、3 つの部分はコロンで結合されて最終的な文字列となります:
\ndef make_key(key, key_prefix, version):\n return "%s:%s:%s" % (key_prefix, version, key)\n各部分をさまざまな方法で組み合わせたり、最終的なキーに他の処理を施したりしたい場合は（例えば、キーの部品のハッシュダイジェストを取るなど）、独自のキー関数を作成できます。
\nKEY_FUNCTION キャッシュ設定では、上記の make_key() のプロトタイプにマッチする関数へのドット区切りパスを指定します。指定された場合、デフォルトのキー結合関数の代わりにこのカスタムキー関数が使用されます。
最も一般的に使用されているキャッシュバックエンドである Memcached は、 250 文字より長いキャッシュキーや、空白文字や制御文字を含むキャッシュキーを許可しておらず、そのようなキーを使用すると例外が発生します。キャッシュ移植可能なコードを推奨し、不快な驚きを最小化するために、他の組み込みキャッシュバックエンドは、 memcached でエラーを引き起こすようなキーが使用された場合、警告 (django.core.cache.backends.base.CacheKeyWarning) を出します。
より広い範囲のキーを使用できるバックエンド (カスタムバックエンド、または非emcachedの組み込みバックエンド) を使用していて、警告を出さずにより広い範囲のキーを使用したい場合は、 INSTALLED_APPS の management モジュールにあるこのコードで CacheKeyWarning を無効にできます:
import warnings\n\nfrom django.core.cache import CacheKeyWarning\n\nwarnings.simplefilter("ignore", CacheKeyWarning)\n組み込みのバックエンドに対してカスタムキーバリデーションのロジックを提供したい場合は、そのバックエンドをサブクラス化して validate_key メソッドだけをオーバーライドし、 using a custom cache backend の説明に従ってください。たとえば、 locmem バックエンドに対してこの処理を行うには、次のコードをモジュールに記述します:
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 ...\nDjango は非同期キャッシュバックエンドのサポートを開発中ですが、非同期キャッシュはまだサポートしていません。将来のリリースで対応する予定です。
\ndjango.core.cache.backends.base.BaseCache には 全ての基本メソッド の非同期バージョンがあります。慣習として、すべてのメソッドの非同期バージョンのプレフィックスは a です。デフォルトでは、両方の引数は同じです:
>>> await cache.aset("num", 1)\n>>> await cache.ahas_key("num")\nTrue\nこれまで、このドキュメントは自分自身が 持つ データに焦点を当ててきました。しかし、ウェブ開発では別の種類のキャッシュも関係があります。それは、「ダウンストリーム」のキャッシュによって実行されるキャッシングです。ユーザーのために、リクエストがウェブサイトに到達する前にもページをキャッシュするシステムが存在します。
\nダウンストリーム キャッシュの例をいくつか挙げます。
\nHTTPを使用する場合、あなたの ISP は特定のページをキャッシュすることがあります。そのため、もしあなたが http://example.com/ からページをリクエストした場合、あなたのISPはexample.comに直接アクセスすることなく、あなたにそのページを送信します。example.comの管理者はこのようなキャッシュを知りません。ISPはexample.comとあなたのウェブブラウザの間に位置し、透過的にすべてのキャッシュを処理します。このようなキャッシュは、中間者攻撃（man-in-the-middle attack）となるため、HTTPSでは不可能です。
あなたの Django ウェブサイトは、Squid Web Proxy Cache (http://www.squid-cache.org/) のような プロキシキャッシュ の背後にあるかもしれません。この場合、各リクエストはまずプロキシによって処理され、必要なときだけアプリケーションに渡されます。
ウェブブラウザもページをキャッシュします。ウェブページが適切なヘッダーを送信すると、ブラウザはそのページへのその後のリクエストに、変更されたかどうかを確認するためにウェブページに再度問い合わせることなく、ローカルにキャッシュされたコピーを使用します。
ダウンストリーム・キャッシュは効率性を高めてくれますが、危険性もあります。 多くのウェブページのコンテンツは、認証や他の変数のホストに基づいて異なっており、純粋にURLに基づいてやみくもにページを保存するキャッシュシステムは、それらのページにあとから訪問する人に不正確なデータや機密データを公開する可能性があります。
\nたとえば、ウェブメールシステムを運営している場合、「受信トレイ」ページの内容は、どのユーザーがログインしているかによって異なります。もしISPがやみくもにあなたのサイトをキャッシュしていたら、そのISP経由で最初にログインしたユーザーは、そのユーザー固有の受信トレイページを、それ以降のサイト訪問者のためにキャッシュすることになります。 それはクールではありません。
\n幸い、HTTP はこの問題の解決方法を提供しています。さまざまな HTTP ヘッダを使用することで、指定した変数に応じてキャッシュ コンテンツを変えるようにダウンストリーム キャッシュに支持したり、特定のページをキャッシュしないようにキャッシュメカニズムに伝えることができます。以下のセクションでは、こうしたヘッダの一部を見ていきます。
\nVary ヘッダーを使うLink to this heading#Vary ヘッダは、キャッシュメカニズムがキャッシュキーを作る際に、どのリクエストヘッダを考慮するべきかを定義します。たとえば、ウェブサイトのコンテンツがユーザーの言語設定に依存する場合、ページは「言語によって異なる (vary)」と言うことができます。
デフォルトでは、Django のキャッシュシステムは、リクエストされた完全修飾 URL (たとえば "https://www.example.com/stories/2005/?order_by=author") を使ってキャッシュキーを作成します。つまり、クッキーや 言語設定などのユーザエージェントの違いに関係なく、その URL へのリクエストはすべて同じキャッシュバージョンを使うことになります。しかし、もしこのページがリクエストヘッダの違い、例えばクッキーや言語、ユーザーエージェントの違いによって異なるコンテンツを生成するのであれば、 Vary ヘッダを使ってキャッシュ機構にページの出力がそれらに依存していることを伝える必要があります。
これを Django で行うには、便利な django.views.decorators.vary.vary_on_headers() ビューデコレータを次のように使います:
from django.views.decorators.vary import vary_on_headers\n\n\n@vary_on_headers("User-Agent")\ndef my_view(request): ...\nこの場合、(Django 自身のキャッシュミドルウェアのような) キャッシュ機構は、それぞれのユニークなユーザエージェントに対して、別バージョンのページをキャッシュします。
\nvary_on_headers デコレータを使用する利点は、手動で Vary ヘッダーを設定する (response.headers['Vary'] = 'user-agent' のように使用する) のではなく、デコレータが Vary ヘッダーに 追加 をする点にあります（これは既に存在するかもしれません）。それにより、最初から設定され、既にそこにあったものを上書きすることを避けることができます。
複数のヘッダを vary_on_headers() に渡すこともできます:
@vary_on_headers("User-Agent", "Cookie")\ndef my_view(request): ...\nこれは、下流のキャッシュに対して 両方 の vary に応じるように指示します。これは、user-agent と cookie の各組み合わせがそれぞれ独自のキャッシュ値を持つことを意味します。例えば、user-agent が Mozilla で cookie の値が foo=bar のリクエストは、user-agent が Mozilla で cookie の値が foo=ham のリクエストとは異なるものとみなされます。
クッキーで変化することはとても一般的なので、 django.views.decorators.vary.vary_on_cookie() デコレータがあります。これら2つのビューは等価です:
@vary_on_cookie\ndef my_view(request): ...\n\n\n@vary_on_headers("Cookie")\ndef my_view(request): ...\nvary_on_headers に渡すヘッダは大文字小文字を区別しません。 "User-Agent" は "user-agent" と同じ意味です。
django.utils.cache.patch_vary_headers() というヘルパー関数を直接使うこともできます。この関数は Vary ヘッダ を設定、または追加します。たとえば次のようにします:
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 は HttpResponse インスタンスを第 1 引数に、大文字小文字を区別しないヘッダ名のリスト/タプルを第 2 引数にとります。
Vary ヘッダについての詳細は 公式な Vary の仕様 を参照してください。
\nキャッシュに関するその他の問題点としては、データのプライバシーや、キャッシュの階層構造のどこにデータを保存すべきかという問題があります。
\nユーザーは通常2種類のキャッシュに直面します。自分のブラウザのキャッシュ（プライベートキャッシュ）とプロバイダのキャッシュ（パブリックキャッシュ）です。パブリックキャッシュは、複数のユーザーによって使用され、他の誰かによって制御されます。これは、機密データに関する問題を引き起こします。例えば、銀行の口座番号がパブリックキャッシュに保存されることは避けたいものです。そのため、ウェブアプリケーションには、どのデータがプライベートで、どのデータがパブリックであるかをキャッシュに伝える方法が必要です。
\n解決策は、ページのキャッシュを "private" にすることです。これを Django で行うには、 cache_control() ビューデコレータを使います。例:
from django.views.decorators.cache import cache_control\n\n\n@cache_control(private=True)\ndef my_view(request): ...\nこのデコレータは、適切な HTTP ヘッダーを背後で送信します。
\nキャッシュ制御の設定 "private" と "public" は互いに排他的であることに注意しましょう。デコレータは、"private" が設定されているときは "public" ディレクティブを削除します (逆も同様です)。2つのディレクティブの使用例は、プライベートとパブリックのエントリを提供するブログサイトです。公開エントリは共有キャッシュにキャッシュされます。以下のコードでは patch_cache_control() を使っています。これはキャッシュコントロールヘッダを手動で変更する方法です (内部的には 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\nダウンストリームのキャッシュは他の方法でも制御できます (HTTP キャッシュの詳細については RFC 9111 を参照してください)。たとえば、 Django のサーバーサイドキャッシュフレームワークを使わない場合でも、 max-age ディレクティブを使って、ビューを一定時間キャッシュするようにクライアントに指示できます:
\nfrom django.views.decorators.cache import cache_control\n\n\n@cache_control(max_age=3600)\ndef my_view(request): ...\n(キャッシュミドルウェアを使用 する 場合、 CACHE_MIDDLEWARE_SECONDS 設定の値で max-age が既に設定されています。その場合、 cache_control() デコレータで指定した max_age が優先され、ヘッダ値は正しくマージされます)。
有効な Cache-Control レスポンスディレクティブはすべて cache_control() で有効です。以下はその例です:
no_transform=True
must_revalidate=True
stale_while_revalidate=num_seconds
no_cache=True
既知のディレクティブの全リストは IANA registry にあります (すべてのディレクティブがレスポンスに適用されるわけではないことに注意してください)。
\nヘッダーを使用してキャッシュを完全に無効にしたい場合は、 never_cache() が使えます。これはビューのデコレータであり、レスポンスがブラウザーや他のキャッシュによってキャッシュされないようにするヘッダーを追加します。例:
from django.views.decorators.cache import never_cache\n\n\n@never_cache\ndef myview(request): ...\nMIDDLEWARE の順序Link to this heading#キャッシュミドルウェアを使用する場合、下記の2つを MIDDLEWARE 設定の適切な場所に配置することが重要です。キャッシュミドルウェアはどのヘッダによってキャッシュストレージを変化させるかを知る必要があるからです。ミドルウェアは常に Vary レスポンスヘッダに何かを追加します。
UpdateCacheMiddleware はレスポンスフェーズの間に実行され、ミドルウェアは逆順に実行されるため、リストの先頭にある項目はレスポンスフェーズの間、 最後に 実行されます。したがって、 UpdateCacheMiddleware が Vary ヘッダに何かを追加する可能性のある他のミドルウェアの 前に 配置されていることを確認する必要があります。以下のミドルウェアモジュールは Vary ヘッダに何らかのものを追加します:
SessionMiddleware は Cookie を追加します
GZipMiddleware は Accept-Encoding を追加します
LocaleMiddleware は Accept-Language を追加します
一方、FetchFromCacheMiddleware はリクエストフェーズで実行され、このフェーズではミドルウェアが先頭から最後にかけて適用されるため、リストの上部にあるアイテムはリクエストフェーズの 最初 に実行されます。 FetchFromCacheMiddleware もまた、他のミドルウェアが Vary ヘッダーを更新した後に実行する必要があるので、 FetchFromCacheMiddleware は Vary ヘッダーを更新するようなアイテムの 後 になければなりません。