Django笔记10(缓存机制)

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/iteye_21297/article/details/81729661
[b]1.设定缓存[/b]
缓存选择在你的settings文件的 CACHE_BACKEND 设置中,如果你使用缓存但没有指定 CACHE_BACKEND ,Django将默认使用 simple:///

[b]2. 内存缓冲[/b]
CACHE_BACKEND = ‘memcached://127.0.0.1:11211/’
CACHE_BACKEND = ‘memcached://172.19.26.240:11211;172.19.26.242:11211/’

[b]3. 数据库缓存[/b]
(1) 使用如下语句创建一个缓存用数据表
python manage.py createcachetable [cache_table_name]
(2) 设置你的CACHE_BACKEND设置为”db://tablename”,这里的tablename是数据库表的名字
CACHE_BACKEND = ‘db://my_cache_table’

[b]4. 文件系统缓存[/b]
CACHE_BACKEND = ‘file:///var/tmp/django_cache’
注意例子中开头有三个前斜线,前两个是file://,第三个是目录路径的第一个字符,/var/tmp/django_cache,如果你使用Windows系统,把盘符字母放在file://后面,像这样:’file://c:/foo/bar’
目录路径应该是*绝对*路径,即应该以你的文件系统的根开始,你在设置的结尾放置斜线与否无关紧要.
每个缓存值将被存储为单独的文件,其内容是Python的pickle模块以序列化(“pickled”)形式保存的缓存数据,每个文件的文件名是缓存键,为安全的文件系统使用释放

[b]5. 本地内存缓存[/b]
CACHE_BACKEND = ‘locmem:///’

[b]6. 简易缓存(用于开发阶段)[/b]
CACHE_BACKEND = ’simple:///’

[b]7. 伪缓存(供开发时使用)[/b]
CACHE_BACKEND = ‘dummy:///’

[b]8. CACHE_BACKEND参数[/b]
每个缓存后端都可能使用参数,它们在CACHE_BACKEND设置中以查询字符串形式给出,合法的参数为:
timeout:用于缓存的过期时间,以秒为单位。这个参数默认被设置为300秒(五分钟)
max_entries : 对于simple, local-memory与database类型的缓存,这个参数是指定缓存中存放的最大条目数,大于这个数时,旧的条目将会被删除。这个参数默认是300.
cull_frequency :当达到 max_entries 的时候,被接受的访问的比率。实际的比率是 1/cull_frequency ,所以设置cull_frequency=2就是在达到 max_entries 的时候去除一半数量的缓存。把 cull_frequency 的值设置为 0 意味着当达到 max_entries 时,缓存将被清空。这将以很多缓存丢失为代价,大大提高接受访问的速度。这个值默认是3
在这个例子中, timeout 被设成 60
CACHE_BACKEND = “locmem:///?timeout=60″
而在这个例子中, timeout 设为 30 而 max_entries 为 400 :
CACHE_BACKEND = “locmem:///?timeout=30&max_entries=400″

[b]9. 站点级 Cache[/b]
一旦你指定了”CACHE_BACKEND”,使用缓存的最简单的方法就是缓存你的整个网站。这意味着所有不包含GET或POST参数的页面在第一次被请求之后将被缓存指定好的一段时间。

MIDDLEWARE_CLASSES = (
'django.middleware.cache.CacheMiddleware',
'django.middleware.common.CommonMiddleware',
)

然后,在你的Django settings文件里加入下面所需的设置:
CACHE_MIDDLEWARE_SECONDS:每个页面应该被缓存的秒数
CACHE_MIDDLEWARE_KEY_PREFIX:如果缓存被多个使用相同Django安装的网站所共享,那么把这个值设成当前网站名,或其他能代表这个Django实例的唯一字符串,以避免key发生冲突。如果你不在意的话可以设成空字符串。

[b]10. 视图级缓存[/b]
更加颗粒级的缓存框架使用方法是对单个视图的输出进行缓存。这和整站级缓存有一样的效果(包括忽略对有 GET 和 POST 参数的请求的缓存)。它应用于你所指定的视图,而不是整个站点。

from django.views.decorators.cache import cache_page

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

[b]11. 在 URLconf 中指定视图缓存[/b]

from django.views.decorators.cache import cache_page

urlpatterns = ('',
(r'^foo/(\d{1,2})/$', cache_page(my_view, 60 * 15)),
)

[b]12. 低层次缓存API[/b]
下面是如何导入这个 API :
>>> from django.core.cache import cache
基本的接口是 set(key, value, timeout_seconds) 和 get(key) :
>>> cache.set(’my_key’, ‘hello, world!’, 30)
>>> cache.get(’my_key’)
‘hello, world!’
timeout_seconds 参数是可选的, 并且默认为前面讲过的 CACHE_BACKEND 设置中的 timeout 参数.
如果对象在缓存中不存在, 或者缓存后端是不可达的, cache.get() 返回 None :
# Wait 30 seconds for ‘my_key’ to expire…
>>> cache.get(’my_key’)
None
>>> cache.get(’some_unset_key’)
None
我们不建议在缓存中保存 None 常量,因为你将无法区分所保存的 None 变量及由返回值 None 所标识的缓存未中。
cache.get() 接受一个 缺省 参数。其指定了当缓存中不存在该对象时所返回的值:
>>> cache.get(’my_key’, ‘has expired’)
‘has expired’
要想一次获取多个缓存值,可以使用 cache.get_many() 。如果可能的话,对于给定的缓存后端, get_many() 将只访问缓存一次,而不是对每个缓存键值都进行一次访问。 get_many() 所返回的字典包括了你所请求的存在于缓存中且未超时的所有键值。
>>> 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.get_many(['a', 'b', 'c', 'd'])
{’a': 1, ‘b’: 2, ‘c’: 3}
最后,你可以用 cache.delete() 显式地删除关键字。这是在缓存中清除特定对象的简单途径。
>>> cache.delete(’a')
cache.delete() 没有返回值, 不管给定的缓存关键字对应的值存在与否, 它都将以同样方式工作。
[b]13. 使用 Vary 头标[/b]
缺省情况下,Django 的缓存系统使用所请求的路径(比如: “/stories/2005/jun/23/bank_robbed/” )来创建其缓存键。这意味着对该 URL 的每个请求都将使用同一个已缓存版本,而不考虑 cookies 或语言偏好之类的 user-agent 差别。然而,如果该页面基于请求头标的区别(例如 cookies、语言或者 user-agent)产生不同内容,你就不得不使用 Vary 头标来通知缓存机制:该页面的输出取决与这些东西。

from django.views.decorators.vary import vary_on_headers
@vary_on_headers('User-Agent', 'Cookie')
def my_view(request):
# ...

传入 vary_on_headers 头标是大小写不敏感的; “User-Agent” 与 “user-agent” 完全相同。
展开阅读全文

没有更多推荐了,返回首页