|
ySJ
|
2.0/chapter15/#262 |
2010-04-22 16:52:54
|
缓存超时时间可以作为模板变量，只要它可以解析为整数值。
|
|
|
ySJ
|
2.0/chapter15/#260 |
2010-04-22 16:50:14
|
简单地把参数传给<literal>{% cache %}</literal>。
|
|
|
ySJ
|
2.0/chapter15/#259 |
2010-04-22 16:49:42
|
传递不止一个参数也是可行的。
|
|
|
ySJ
|
2.0/chapter15/#256 |
2010-04-22 16:47:38
|
这样只需要给<literal>{% cache %}</literal>传递额外的参数以标识缓存片段。
|
|
|
ySJ
|
2.0/chapter15/#255 |
2010-04-22 16:45:17
|
比如，你想为上一个例子的每个用户分别缓存侧边栏。
|
|
|
ySJ
|
2.0/chapter15/#254 |
2010-04-22 16:43:55
|
有时你可能想缓存基于片段的动态内容的多份拷贝。
|
|
|
ySJ
|
2.0/chapter15/#250 |
2010-04-22 16:42:02
|
缓存超时时间（以秒计）和指定缓存片段的名称。
|
|
|
ySJ
|
2.0/chapter15/#248 |
2010-04-22 16:41:04
|
模板标签<literal>{% cache %}</literal>在给定的时间内缓存了块的内容。
|
|
|
ySJ
|
2.0/chapter15/#246 |
2010-04-22 16:39:54
|
在模板的顶端附近加入<literal>{% load cache %}</literal>以通知模板存取缓存标签。
|
|
|
ySJ
|
2.0/chapter15/#245 |
2010-04-22 16:38:00
|
你同样可以使用<literal>cache</literal>标签来缓存模板片段。
|
|
|
ySJ
|
2.0/chapter15/#241 |
2010-04-22 16:34:44
|
如果采取这种方法, 不要忘记在 URLconf 中导入 <literal>cache_page</literal>。
|
|
|
ySJ
|
2.0/chapter15/#235 |
2010-04-22 16:34:03
|
这是之前的URLconf：
|
|
|
ySJ
|
2.0/chapter15/#213 |
2010-04-22 16:28:18
|
以秒计的缓存超时时间。
|
|
|
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
|
每个文件的名称是缓存键，以规避开安全文件系统的使用。
|
|
