|
ySJ
|
2.0/chapter15/#209 |
2010-04-22 16:27:59
|
也可以使用Python2.4的装饰器语法：
|
|
|
ySJ
|
2.0/chapter15/#205 |
2010-04-22 16:27:33
|
<literal>django.views.decorators.cache</literal>定义了一个自动缓存视图响应的<literal>cache_page</literal>装饰器。
|
|
|
ySJ
|
2.0/chapter15/#200 |
2010-04-22 16:24:22
|
请参阅下面的”使用其他头部信息“小节以了解装饰器的更多信息。
|
|
|
ySJ
|
2.0/chapter15/#199 |
2010-04-22 16:20:37
|
它有一个最大年龄在头部信息的<literal>Cache-Control</literal>中），那么页面将缓存直到过期，而不是CACHE_MIDDLEWARE_SECONDS。使用django.views.decorators.cache装饰器，您可以轻松地设置视图的到期时间（使用cache_control装饰器）或禁用缓存视图（使用never_cache装饰器）。
|
|
|
ySJ
|
2.0/chapter15/#194 |
2010-04-22 16:14:33
|
设置Cache-Control头部来给页面一个最长的有效期，值来自于CACHE_MIDDLEWARE_SECONDS设置。
|
|
|
ySJ
|
2.0/chapter15/#192 |
2010-04-22 16:13:22
|
设置Expires头部为当前日期/时间加上定义的CACHE_MIDDLEWARE_SECONDS。
|
|
|
ySJ
|
2.0/chapter15/#190 |
2010-04-22 16:12:59
|
当一个新(没缓存的)版本的页面被请求时设置Last-Modified头部为当前日期/时间。
|
|
|
ySJ
|
2.0/chapter15/#188 |
2010-04-22 16:11:56
|
此外，缓存中间件为每个HttpResponse自动设置了几个头部信息：
|
|
|
ySJ
|
2.0/chapter15/#184 |
2010-04-22 16:10:53
|
或者，如果CACHE_MIDDLEWARE_ANONYMOUS_ONLY设置为True，只有匿名请求（即不是由登录的用户）将被缓存。
|
|
|
ySJ
|
2.0/chapter15/#183 |
2010-04-22 16:09:38
|
缓存中间件缓存每个没有GET或者POST参数的页面。
|
|
|
ySJ
|
2.0/chapter15/#178 |
2010-04-22 15:49:52
|
<literal>CACHE_MIDDLEWARE_SECONDS</literal> :每个页面应该被缓存的秒数。
|
|
|
ySJ
|
2.0/chapter15/#174 |
2010-04-22 15:49:26
|
细节有点费解，如果您想了解完整内幕请参看下面的MIDDLEWARE_CLASSES顺序。
|
|
|
ySJ
|
2.0/chapter15/#173 |
2010-04-22 15:47:39
|
修改的中间件，必须放在列表的开始位置，而fectch中间件，必须放在最后。
|
|
|
ySJ
|
2.0/chapter15/#172 |
2010-04-22 15:46:21
|
不，这里并没有排版错误：
|
|
|
ySJ
|
2.0/chapter15/#167 |
2010-04-22 15:45:02
|
您
需要添加'django.middleware.cache.UpdateCacheMiddleware'和
'django.middleware.cache.FetchFromCacheMiddleware'到您的MIDDLEWARE_CLASSES设置中，在这个例子中是：
|
|
|
ySJ
|
2.0/chapter15/#151 |
2010-04-22 15:43:18
|
实际的比率是 <literal>1/cull_percentage</literal> ,所以设置cull_frequency=2就是在达到 <literal>max_entries</literal> 的时候去除一半数量的缓存。
|
|
|
ySJ
|
2.0/chapter15/#150 |
2010-04-22 15:42:59
|
<literal>cull_percentage</literal> :当达到 <literal>max_entries</literal> 的时候,被删除的条目比率。
|
|
|
ySJ
|
2.0/chapter15/#150 |
2010-04-22 15:42:33
|
<literal>cull_frequency</literal> :当达到 <literal>max_entries</literal> 的时候,被删除的条目比率。
|
|
|
ySJ
|
2.0/chapter15/#148 |
2010-04-22 15:41:15
|
这个参数默认是300。
|
|
|
ySJ
|
2.0/chapter15/#147 |
2010-04-22 15:41:02
|
max_entries：对于内存，文件系统和数据库后端，高速缓存允许的最大条目数，超出这个数则旧值将被删除。
|
|
|
ySJ
|
2.0/chapter15/#145 |
2010-04-22 15:38:05
|
这个参数默认被设置为300秒（五分钟）。
|
|
|
ySJ
|
2.0/chapter15/#141 |
2010-04-22 15:37:17
|
它们在CACHE_BACKEND设置中以查询字符串形式给出。
|
|
|
ySJ
|
2.0/chapter15/#140 |
2010-04-22 15:36:03
|
每个缓存后端都可能使用参数。
|
|
|
ySJ
|
2.0/chapter15/#136 |
2010-04-22 15:35:08
|
它们经过大量测试，并且易于使用。
|
|
|
ySJ
|
2.0/chapter15/#135 |
2010-04-22 15:34:05
|
如果没有一个真正令人信服的理由，比如主机不支持，你就应该坚持使用Django包含的缓存后端。
|
|
|
ySJ
|
2.0/chapter15/#132 |
2010-04-22 15:32:15
|
源代码在Django的代码目录的django/core/cache/backends/下。
|
|
|
ySJ
|
2.0/chapter15/#131 |
2010-04-22 15:31:08
|
如果您构建自己的后端，你可以参考标准缓存后端的实现。
|
|
|
ySJ
|
2.0/chapter15/#128 |
2010-04-22 15:30:24
|
要让Django使用外部缓存后端，需要使用一个Python import路径作为的CACHE_BACKEND URI的（第一个冒号前的部分），像这样：
|
|
|
ySJ
|
2.0/chapter15/#127 |
2010-04-22 15:23:04
|
尽管Django包含对许多缓存后端的支持，在某些情况下，你仍然想使用自定义缓存后端。
|
|
|
ySJ
|
2.0/chapter15/#121 |
2010-04-22 15:18:05
|
假如你有一个产品站点，在许多地方使用高度缓存，但在开发/测试环境中，你不想缓存，也不想改变代码，这就非常有用了。
|
|
|
ySJ
|
2.0/chapter15/#119 |
2010-04-22 15:16:05
|
最后，Django提供了一个假缓存（只是实现了缓存接口，实际上什么都不做）。
|
|
|
ySJ
|
2.0/chapter15/#115 |
2010-04-22 15:14:57
|
对开发来说还不错。
|
|
|
ySJ
|
2.0/chapter15/#114 |
2010-04-22 15:14:09
|
这显然也意味着本地内存缓存效率并不是特别高，所以对产品环境来说它可能不是一个好选择。
|
|
|
ySJ
|
2.0/chapter15/#113 |
2010-04-22 15:13:05
|
请注意，每个进程都有自己私有的缓存实例，这意味着跨进程缓存是不可能的。
|
|
|
ySJ
|
2.0/chapter15/#108 |
2010-04-22 15:11:26
|
如果你想利用内存缓存的速度优势，但又不能使用Memcached，可以考虑使用本地存储器缓存后端。
|
|
|
ySJ
|
2.0/chapter15/#108 |
2010-04-22 15:11:08
|
如果你想利用内存缓存的速度优势，但没有能力运行Memcached，可以考虑使用本地存储器缓存后端。
|
|
|
ySJ
|
2.0/chapter15/#104 |
2010-04-22 15:10:01
|
每个文件的名称是缓存键，以规避开安全文件系统的使用。
|
|
|
ySJ
|
2.0/chapter15/#103 |
2010-04-22 15:09:32
|
每个缓存值将被存储为单独的文件，其内容是Python的pickle模块以序列化("pickled")形式保存的缓存数据。
|
|
|
ySJ
|
2.0/chapter15/#101 |
2010-04-22 15:06:32
|
继续上面的例子，如果你的服务器以用户apache运行，确认/var/tmp/django_cache存在并且用户apache可以读写/var/tmp/django_cache目录。
|
|
|
ySJ
|
2.0/chapter15/#100 |
2010-04-22 15:06:07
|
确认该设置指向的目录存在并且你的Web服务器运行的系统的用户可以读写该目录。
|
|
|
ySJ
|
2.0/chapter15/#98 |
2010-04-22 15:05:20
|
在设置的结尾放置斜线与否无关紧要。
|
|
|
ySJ
|
2.0/chapter15/#97 |
2010-04-22 15:05:10
|
目录路径应该是*绝对*路径，即应该以你的文件系统的根开始。
|
|
|
ySJ
|
2.0/chapter15/#94 |
2010-04-22 15:03:26
|
头两项是file://，第三个是第一个字符的目录路径，/var/tmp/django_cache。如果你使用的是Windows，在file://之后加上文件的驱动器号：
|
|
|
ySJ
|
2.0/chapter15/#93 |
2010-04-22 15:02:14
|
注意例子中开头有三个斜线。
|
|
|
ySJ
|
2.0/chapter15/#93 |
2010-04-22 15:02:06
|
注意例子中开头有三个前斜线。
|
|
|
ySJ
|
2.0/chapter15/#90 |
2010-04-22 15:00:38
|
要把缓存项目放在文件系统上，请为CACHE_BACKEND使用"file://"的缓存类型。例如，要把缓存数据存储在/var/tmp/django_cache上，请使用此设置：
|
|
|
ySJ
|
2.0/chapter15/#86 |
2010-04-22 14:58:55
|
如果你已经有了一个快速，良好的索引数据库服务器，那么数据库缓存的效果最明显。
|
|
|
ySJ
|
2.0/chapter15/#84 |
2010-04-22 14:57:56
|
你不能为你的缓存表使用不同的数据库后端.
|
|
|
ySJ
|
2.0/chapter15/#83 |
2010-04-22 14:57:41
|
数据库缓存后端使用你的settings文件指定的同一数据库。
|
|
|
ySJ
|
2.0/chapter15/#79 |
2010-04-22 14:57:02
|
一旦你创建了数据库表，把你的CACHE_BACKEND设置为"db://tablename"，这里的tablename是数据库表的名字，在这个例子中，缓存表名为my_cache_table:
|
|
