|
ySJ
|
2.0/chapter15/#49 |
2010-04-22 14:30:05
|
如果您无法安装cmemcache，您可以安装python - Memcached，在ftp://ftp.tummy.com/pub/python-memcached/。如果该网址已不再有效，只要到Memcached的网站http://www.danga.com/memcached/），并从客户端API完成Python绑定。
|
|
|
ySJ
|
2.0/chapter15/#51 |
2010-04-22 14:30:56
|
若要使用Memcached的Django，设置CACHE_BACKEND到memcached：/ / IP：port/，其中IP是Memcached的守护进程的IP地址，port是Memcached运行的端口。
|
|
|
ySJ
|
2.0/chapter15/#56 |
2010-04-22 14:31:53
|
Memcached的一个极好的特性是它在多个服务器间分享缓存的能力。
|
|
|
ySJ
|
2.0/chapter15/#57 |
2010-04-22 14:32:36
|
这意味着您可以在多台机器上运行Memcached的守护进程，该程序会当成一个单一缓存组机器，而无需重复每台机器上的缓存值。
|
|
|
ySJ
|
2.0/chapter15/#57 |
2010-04-22 14:33:02
|
这意味着您可以在多台机器上运行Memcached的守护进程，该程序会把这些机器当成一个单一缓存，而无需重复每台机器上的缓存值。
|
|
|
ySJ
|
2.0/chapter15/#58 |
2010-04-22 14:33:35
|
要充分利用此功能，请在CACHE_BACKEND里引入所有服务器的地址，用分号分隔。
|
|
|
ySJ
|
2.0/chapter15/#60 |
2010-04-22 14:34:40
|
这个例子中，缓存在运行在IP地址为172.19.26.240和172.19.26.242，端口号为11211的Memcached实例间分享:
|
|
|
ySJ
|
2.0/chapter15/#66 |
2010-04-22 14:35:13
|
最后关于Memcached的是基于内存的缓存有一个重大的缺点。
|
|
|
ySJ
|
2.0/chapter15/#66 |
2010-04-22 14:35:42
|
最后有关Memcached的一点是，基于内存的缓存有一个重大的缺点。
|
|
|
ySJ
|
2.0/chapter15/#67 |
2010-04-22 14:36:18
|
由于缓存的数据存储在内存中，所以如果您的服务器崩溃，数据将会消失。
|
|
|
ySJ
|
2.0/chapter15/#68 |
2010-04-22 14:37:47
|
显然，内存不是用来持久化数据的，因此不要吧基于内存的缓存作为您唯一的存储数据缓存。
|
|
|
ySJ
|
2.0/chapter15/#68 |
2010-04-22 14:37:58
|
显然，内存不是用来持久化数据的，因此不要把基于内存的缓存作为您唯一的存储数据缓存。
|
|
|
ySJ
|
2.0/chapter15/#69 |
2010-04-22 14:47:17
|
毫无疑问，在Django的缓存后端不应该用于持久化，它们本来就被设计成缓存的解决方案。但我们仍然指出此点，这里是因为基于内存的缓存是暂时的。
|
|
|
ySJ
|
2.0/chapter15/#73 |
2010-04-22 14:48:18
|
为了使用数据库表作为缓存后端，首先在数据库中运行这个命令以创建缓存表：
|
|
|
ySJ
|
2.0/chapter15/#76 |
2010-04-22 14:50:17
|
这里的[cache_table_name]是要创建的数据库表名。
|
|
|
ySJ
|
2.0/chapter15/#77 |
2010-04-22 14:53:12
|
（这个名字随你的便，只要它是一个有效的表名，而且不是已经在您的数据库中使用的表明。）这个命令以Django的数据库缓存系统所期望的格式创建一个表。
|
|
|
ySJ
|
2.0/chapter15/#77 |
2010-04-22 14:56:40
|
（这个名字随你的便，只要它是一个有效的表名，而且不是已经在您的数据库中使用的表名。）这个命令以Django的数据库缓存系统所期望的格式创建一个表。
|
|
|
ySJ
|
2.0/chapter15/#79 |
2010-04-22 14:57:02
|
一旦你创建了数据库表，把你的CACHE_BACKEND设置为"db://tablename"，这里的tablename是数据库表的名字，在这个例子中，缓存表名为my_cache_table:
|
|
|
ySJ
|
2.0/chapter15/#83 |
2010-04-22 14:57:41
|
数据库缓存后端使用你的settings文件指定的同一数据库。
|
|
|
ySJ
|
2.0/chapter15/#84 |
2010-04-22 14:57:56
|
你不能为你的缓存表使用不同的数据库后端.
|
|
|
ySJ
|
2.0/chapter15/#86 |
2010-04-22 14:58:55
|
如果你已经有了一个快速，良好的索引数据库服务器，那么数据库缓存的效果最明显。
|
|
|
ySJ
|
2.0/chapter15/#90 |
2010-04-22 15:00:38
|
要把缓存项目放在文件系统上，请为CACHE_BACKEND使用"file://"的缓存类型。例如，要把缓存数据存储在/var/tmp/django_cache上，请使用此设置：
|
|
|
ySJ
|
2.0/chapter15/#93 |
2010-04-22 15:02:06
|
注意例子中开头有三个前斜线。
|
|
|
ySJ
|
2.0/chapter15/#93 |
2010-04-22 15:02:14
|
注意例子中开头有三个斜线。
|
|
|
ySJ
|
2.0/chapter15/#94 |
2010-04-22 15:03:26
|
头两项是file://，第三个是第一个字符的目录路径，/var/tmp/django_cache。如果你使用的是Windows，在file://之后加上文件的驱动器号：
|
|
|
ySJ
|
2.0/chapter15/#97 |
2010-04-22 15:05:10
|
目录路径应该是*绝对*路径，即应该以你的文件系统的根开始。
|
|
|
ySJ
|
2.0/chapter15/#98 |
2010-04-22 15:05:20
|
在设置的结尾放置斜线与否无关紧要。
|
|
|
ySJ
|
2.0/chapter15/#100 |
2010-04-22 15:06:07
|
确认该设置指向的目录存在并且你的Web服务器运行的系统的用户可以读写该目录。
|
|
|
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/#103 |
2010-04-22 15:09:32
|
每个缓存值将被存储为单独的文件，其内容是Python的pickle模块以序列化("pickled")形式保存的缓存数据。
|
|
|
ySJ
|
2.0/chapter15/#104 |
2010-04-22 15:10:01
|
每个文件的名称是缓存键，以规避开安全文件系统的使用。
|
|
|
ySJ
|
2.0/chapter15/#108 |
2010-04-22 15:11:08
|
如果你想利用内存缓存的速度优势，但没有能力运行Memcached，可以考虑使用本地存储器缓存后端。
|
|
|
ySJ
|
2.0/chapter15/#108 |
2010-04-22 15:11:26
|
如果你想利用内存缓存的速度优势，但又不能使用Memcached，可以考虑使用本地存储器缓存后端。
|
|
|
ySJ
|
2.0/chapter15/#113 |
2010-04-22 15:13:05
|
请注意，每个进程都有自己私有的缓存实例，这意味着跨进程缓存是不可能的。
|
|
|
ySJ
|
2.0/chapter15/#114 |
2010-04-22 15:14:09
|
这显然也意味着本地内存缓存效率并不是特别高，所以对产品环境来说它可能不是一个好选择。
|
|
|
ySJ
|
2.0/chapter15/#115 |
2010-04-22 15:14:57
|
对开发来说还不错。
|
|
|
ySJ
|
2.0/chapter15/#119 |
2010-04-22 15:16:05
|
最后，Django提供了一个假缓存（只是实现了缓存接口，实际上什么都不做）。
|
|
|
ySJ
|
2.0/chapter15/#121 |
2010-04-22 15:18:05
|
假如你有一个产品站点，在许多地方使用高度缓存，但在开发/测试环境中，你不想缓存，也不想改变代码，这就非常有用了。
|
|
|
ySJ
|
2.0/chapter15/#127 |
2010-04-22 15:23:04
|
尽管Django包含对许多缓存后端的支持，在某些情况下，你仍然想使用自定义缓存后端。
|
|
|
ySJ
|
2.0/chapter15/#128 |
2010-04-22 15:30:24
|
要让Django使用外部缓存后端，需要使用一个Python import路径作为的CACHE_BACKEND URI的（第一个冒号前的部分），像这样：
|
|
|
ySJ
|
2.0/chapter15/#131 |
2010-04-22 15:31:08
|
如果您构建自己的后端，你可以参考标准缓存后端的实现。
|
|
|
ySJ
|
2.0/chapter15/#132 |
2010-04-22 15:32:15
|
源代码在Django的代码目录的django/core/cache/backends/下。
|
|
|
ySJ
|
2.0/chapter15/#135 |
2010-04-22 15:34:05
|
如果没有一个真正令人信服的理由，比如主机不支持，你就应该坚持使用Django包含的缓存后端。
|
|
|
ySJ
|
2.0/chapter15/#136 |
2010-04-22 15:35:08
|
它们经过大量测试，并且易于使用。
|
|
|
ySJ
|
2.0/chapter15/#140 |
2010-04-22 15:36:03
|
每个缓存后端都可能使用参数。
|
|
|
ySJ
|
2.0/chapter15/#141 |
2010-04-22 15:37:17
|
它们在CACHE_BACKEND设置中以查询字符串形式给出。
|
|
|
ySJ
|
2.0/chapter15/#145 |
2010-04-22 15:38:05
|
这个参数默认被设置为300秒（五分钟）。
|
|
|
ySJ
|
2.0/chapter15/#147 |
2010-04-22 15:41:02
|
max_entries：对于内存，文件系统和数据库后端，高速缓存允许的最大条目数，超出这个数则旧值将被删除。
|
|
|
ySJ
|
2.0/chapter15/#148 |
2010-04-22 15:41:15
|
这个参数默认是300。
|
|
|
ySJ
|
2.0/chapter15/#150 |
2010-04-22 15:42:33
|
<literal>cull_frequency</literal> :当达到 <literal>max_entries</literal> 的时候,被删除的条目比率。
|
|
