使用Django的缓存功能，通过Memcached对页面显示进行更高效的加速

2 年 ago

清, 扬

1 minute

首先

我使用Django的缓存功能来尝试加快页面加载速度。

这次，我们选择将缓存存储在Memcached中。

您也可以使用文件或数据库作为其他存储选项。

请参考先前的文章“使用Django缓存功能来加快页面加载速度——数据库部分”，了解关于将数据库作为缓存的方法以及在进行缓存设置前后的处理时间比较。

这篇文章的结构

让我们看看Memcached是如何改变Django的运行方式的

这里要解释的是只在开发服务器上使用Memcached的方法，如果要在生产环境中使用，你需要适当修改settings.py的设置。

请参考以下内容，关于在Heroku环境下使用Django和Memcached的方法，作为一个实际的生产环境示例。

Djangoのキャッシュ機能をHerokuで使う Memcached Cloud編

环境

python-memcached 1.59

在Django的开发服务器中使用Memcached的方法

1.1. 进行Memcached的安装。

$brew install memcached

1.2. 启动Memcached

$ brew services start memcached

1.3. 安装 python-memcached

为了使用python在memcached上，需要安装python-memcached。

(myvenv) $ pip install python-memcached

在settings.py文件中进行缓存设置。

将以下内容添加到settings.py文件中。

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.MemcachedCache',
        'LOCATION': '127.0.0.1:11211',
    }
}

如果要使用Memcached，BACKEND部分表示缓存存储类型，应指定为memcached.MemcachedCache。

在这个位置，指定了Memcached服务器和端口号。如果Django开发服务器的IP地址是127.0.0.1，那么就指定为127.0.0.1:11211。11211是Memcached的默认端口号。

1.5. 指定要进行缓存的对象。

这次决定只缓存访问量较高的特定URL页面。在这种情况下，我们需要在urls.py文件中指定要缓存的目标。

如果原本的urls.py文件内容如下…

from django.urls import path
from . import views

urlpatterns = [
    path('', views.ArticleListView.as_view(), name='article_list'),
    # 略
]

使用cache_page函数如下。将秒数部分写为60 * 15，以便清楚地表示15分钟。

from django.urls import path
from django.views.decorators.cache import cache_page # ここを追加
from . import views


urlpatterns = [
    # cache_page(秒数)(ビュー)を追加する
    path('', cache_page(60 * 15)(views.ArticleListView.as_view()), name='article_list'),
    # 略
]

看看缓存是如何改变Django的运行方式的

我决定使用django-debug-toolbar的功能来查看在缓存设置前后有何变化。

我是根据以下内容参考了设置django-debug-toolbar的方法。

Django笔记(14)：使用Django Debug Toolbar显示调试信息

2.1. 没有缓存设置（停止了Memcached）。

$ brew services stop memcached

画面展示的是我自己开发的Django应用程序。
右侧的黑色工具栏部分显示的是由django-debug-toolbar提供的信息。
“时刻”下显示的应该是CPU的处理时间。大约需要163毫秒。
此外，还发出了3个SQL查询请求。

顺便提一下，处理时间的分配如下所示。

2.2. 当存在缓存设置（memcached正在运行）时的首次访问。

在之前的文章中，我们将缓存保存到数据库中。然而，在这种情况下，由于需要在首次访问时写入缓存表，反而导致处理时间增加，这带来了一些弊端。

处理时间增加了约335毫秒（+154毫秒）。
同时，SQL的发行数量也增加了14条（+9条）。

SQL数量增加是因为执行了对缓存表的读写操作。
发出了用于检查缓存是否存在的SQL，以及（因为缓存不存在）将页面信息写入缓存的SQL。

对于Memcached，会发生什么呢？

在启动Memcached之后，访问屏幕。

$ brew services start memcached

和访问 Memcached 停止时相比，处理时间几乎没有变化，约为 164 毫秒（+1 毫秒）。
此外，SQL 的发行数量仍然为 3 个，没有增加。

2.3. 访问具有缓存设置的第二次访问时

处理时间已大幅减少，约为9毫秒（减少了154毫秒）。
此外，SQL查询次数为0次（减少了3次）。

总结

在Memcached的情况下

条件CPU処理時間(ms)SQL本数キャッシュ設定無し1633キャッシュ設定あり・初回アクセス1643キャッシュ設定あり・2回目のアクセス100

只访问一次并没有进行严格的验证，但是在第一次访问时，与没有缓存设置的情况相比，屏幕显示所需的时间并不会增加，而且预计第二次及以后的访问时间将大大缩短。

顺便说一下，如果是关于数据库的情况

在同一个Django应用程序中，如果将缓存保存到数据库中，也会记录处理时间。

看到这个结果，保存缓存的位置似乎比数据库更适合选择Memcached。

条件CPU処理時間(ms)SQL本数キャッシュ設定無し1633キャッシュ設定あり・初回アクセス32612キャッシュ設定あり・2回目のアクセス222

请参考

macでmemcachedを導入する手順