cache | 伪架构师

Drupal 8 的动态页面缓存

Wed, 14 Oct 2015 22:09:07 +0800

Drupal 8 现在有了动态页面缓存。Page Cache 模块只对匿名用户生效，而 Dynamic Page Cache 模块则更进一步的为所有用户提供服务。

4 月 8 日起，Drupal 8 缺省开启了页面缓存。刚好五个月以后也就是 9 月 8 日，Dynamic Page Cache 模块也加入了 Drupal 8，同样的也是缺省开启。

动态页面缓存是什么？

Page Cache 模块缓存的是完全渲染之后的 HTML 响应内容

他假设每个响应只有一种，这个假设只对匿名用户有效。相对于 Drupal 7，8 的创新是加入了 Cache Tags(缓存标记)，这就使得在使用页面缓存的时候，依然能够及时更新页面，不再呈现过期内容。

Dynamic Page Cache 模块缓存大部分渲染之后的 HTML 相应内容

现在不再认为只有一种响应了：这里要感谢 cache contexts，他能够获取到页面各个部分的变体。在渲染过程中，自动占位会识别页面中的一部分不可缓存的内容，替换为占位符。这些占位符只在最后一刻进行渲染。动态页面缓存模块会在这些占位符被替换之前进行缓存。

所以，概念上来说：Page Cache –> Dynamic Page Cache

	Key	Value
Page Cache	`URL`	`最终响应` `缓存标记`
Dynamic Page Cache	`URL` `cache contexts`	`部分响应` `占位符` `缓存标记`

上表对比展示了二者的优劣：Page Cache 包含了最终响应，所以相对较快；而 Dynamic Page Cache 只包含了部分响应，但是因为这部分内容是没有经过个性化的，所以适用于各种用户。

换句话说，动态页面缓存做的事情比较多，但是适用于更多场景。

Benchmark

在开启页面缓存之后，Drupal 8 对匿名用户能够在常数时间内返回响应。

有了动态页面缓存之后，Drupal 8 的响应时间就是在之前的时间上再加上渲染占位符的时间。这意味着，页面的绝大部分能够在固定时间里完成（跟内容多少无关）。最后的占位符渲染环节是最需要进行优化的，当然，最好没有这部分（可以延伸阅读一下 BigPipe 相关内容）。

在我的机器上（ab -c1 -n 1000, PHP 5.5.11，Intel Core i7 2.8 GHz 笔记本电脑，15 个带有一条留言的 Node，其中 10 个列在首页上）：

没有动态页面缓存
- 首页：61.3 毫秒/请求（每秒 16 个请求）
- node/1：92.3 毫秒/请求（每秒 10.8 个请求）
动态缓存开启
- 首页：38.3 毫秒/请求（每秒 26 个请求）
- node/1：73.8 毫秒/请求（每秒 13.5 个请求）

分析

首页只有一个占位符（message），这使得首页是一个最低相应时间的指标：我的机器上大概 38 毫秒。

大约 38 毫秒用于 bootstrap，路由，路由权限检查，从动态页面缓存中获取缓存内容。
跟 node/1 比较：渲染占位符用掉了超过 35.5 毫秒的时间。这说明此处的渲染成本非常高——留言 Form。

可以看到，动态页面缓存在开发期间也很有用，他暴露了无法缓存或者难于渲染的页面部分。

在实际服务器上，十倍不止

上面的测试只是一个并发，还可以参考Rasmus Lerdorf 的相关测试

多赢

各种规模的站点都会受益：

企业级站点得到了更高的可塑性，以及针对认证用户的反向代理/CDN方面能力的提升。
小站点能够为认证用户提供更多更快的并发访问能力。

所以我的工作由 Acquia 赞助，但是大家都能从中获益。

有人发表疑问， Drupal 8 会不会太复杂了，是不是已经不在意站点搭建者，而只考虑企业应用了之类的、我认为这就是个很好的反例 —— 缺省激活的页面缓存优于大多数的 Drupal 7 站点。

我们的确在缓存标记上增加了复杂性，不过这只对开发者产生了影响，而且提供了完善的文档。最重要的是，站点建设者不需要关心这些了，Drupal 8 开始不再需要手工清除缓存了！

Drupal 很像乐高积木。直到 Drupal 8，如果你试用了太多的模块，站点会变慢，缓存的设置复杂到令人望而却步。现在这些组成部分必须自己声明缓存的元数据，这样 Drupal 就可以把大部分“加速”工作自动完成了。

小站点（包括共享主机）

小站点能够处理更多的认证用户产生的并发访问，更快的生成页面。

无需任何配置。

无需任何搜索。

企业站点（以及企业级托管）

企业站点有了更多调节的能力：如果倾向于利用足够的存储空间，而不是渲染占位符的话（空间换时间），那么只要覆盖缺省的自动占位符条件即可。

这也是第一次我们有机会利用CDN为认证用户提供响应内容。

开发者

在缓存元数据（缓存标记，上下文和最大周期）之外，可以针对主机环境，性能和缓存方面做深入细致的调整。而之前，必须分析和调试一大坨代码，来判断为什么有些缓存没有在合适的时候过期。

原因是，现在的整个过程被标准化了，我们可以使用更好的工具——甚至可以自动的检测类似问题：不合适的缓存上下文，过低的缓存生命周期，过于频繁的缓存失效。

最后，这一切使得 Drupal 8 成为最快的 Drupal

Drupal 8 的动态页面缓存 vs Drupal 7 的 Authcache

动态页面缓存在 Drupal 7 中最相近内容应该就是 Authcache 模块了。在 Drupal 7 中使用 Authcache 也能获得非常好的性能，但是这需要大量的工作：所有的代码（第三方的和自行实现的）必须进行分析，以保证所有的输出过程中所有需要进行缓存验证的部分都对应到账号。所有的因素必须都传递给 Authcache，来进行缓存键的计算。“关键属性”的概念和 Drupal 8 的缓存上下文类似。然而，这个过程很容易漏掉一些因素。这是因为站点的所有者要负责识别所有的验证，这里包含所有的模块和页面。缺省情况下，Authcache 假设用站点的 base URL 和用户的角色来进行区分。所以除非你的站点非常简单（可能连多语言都不支持），否则就要进行很多的研究来用好 Authcache。

（例如目前还在运行 Drupal 7 的 Drupal.org，几个月前推出了针对评论的渲染缓存功能。他的工作方式很像 Authcache：必须指定引起缓存校验的因素。有个因素（时区）被忽略了，结果导致了奇怪的输出结果。强如 Durpal.org 的团队，也发生了这种错误，我们如何能够寄希望于其他团队呢？）

Drupal 8 中的动态页面缓存建立在缓存元数据概念之上。不需要自定义钩子，也无需用户参与。缓存行为现在是模块的责任，有理由相信，模块作者更知道模块的功能，因此也无需再次进行代码分析。动态缓存还支持缓存标记，所以跟 Drupal 7 的 Authcache 不同，动态页面缓存能够及时进行更新。

在 Drupal 8.0.0 中，动态页面缓存在 bootstrap、路由、路由访问控制之后执行。而因为 Authcache 做了一些简单假设，他能够在完全执行完 bootstrap 之前执行，这样无疑是更快的。我们也正在一个 issue （#2541284）中提出这个问题，这一问题如果得以解决，能够得到巨大的性能提升，我们会在 Drupal 8 未来的某个版本中发布出来。

最后因为 Drupal 8 中缺省就启用了动态页面缓存，所以他直接为所有的开发者和所有的站点产生巨大的影响。建议所有的 Drupal 开发者在代码中定制合适的缓存上下文。这样 Drupal 8 的模块就会被为数众多的网站所考验，遗失的缓存元数据也就可以迅速修正。所有用户一起来完成这一任务，而不是像 Authcache 用户那样单打独斗。

Drupal静态缓存

Wed, 05 Aug 2015 10:32:19 +0800

Drupal的伸缩性是存在的，而且非常强大。当我们问别人对Drupal的看法时候，多数时间得到的答案是：据说那东西很慢。在我的工作中见到过很多性能低下的Drupal站点，缓存是其中的重要原因。即使是基础的Drupal安装，其中也包含了一套针对数据表的多层缓存，不幸的是，这一缓存体系很容易被开发者破坏。

阻碍缓存的最大原因可能就是在自定义模块中错过了利用缓存提升性能的机会。把计算后的结果保存在PHP变量中，接下来的调用过程可能会得到成百上千倍的性能提升。要使用这一技巧只需要很小成本：如果一个结果已经得出，就返回这一结果；否则，运算得到结果之后，首先保存结果，然后才返回。

    function apachesolr_static_response_cache($searcher, $response = NULL) {
      $_response = &drupal_static(__FUNCTION__, array());

      if (is_object($response)) {
        $_response[$searcher] = clone $response;
      }
      if (!isset($_response[$searcher])) {
        $_response[$searcher] = NULL;
      }
      return $_response[$searcher];
    }

Apache Solr模块在很多地方使用了静态缓存，例如即使一个页面上存在多个搜索相关的Block，也保证每次请求只执行一个Solr搜索。

和其他缓存方案一样，缓存命中时候的访问速度和缓存未命中时的差异决定了缓存的效益。耗时长、执行频繁并且经常返回重复值的函数，通过缓存能够获得最好的收益，这一标准非常清晰，Drupal很多代码符合这一要求。

很多重负载的核心函数进行了静态缓存：menu.module使用了一个树状的数据结构，这意味着需要做很多重复的递归工作。当页面上有多处使用菜单的情况下，有了静态缓存的帮助，处理时间得到了极大的缩减。类似的还有Drupal的分类系统——在列表或画廊页面中，分类词的处理可能要进行非常多的次数。在taxonomy.module中的五个函数包含了对drupal_static()的调用，用于加速重复工作。

Drupal中还有一类函数，他们的执行非常快速，但是在很多位置调用，并且返回结果几乎不会变化。drupal_is_front_page()以及drupal_page_is_cacheable()只是简单的检查，一个更好的例子是ip_address()。这个函数需要处理HTTP头中的X-Forwarded-For，用于确定用户的真实IP地址，这需要字符串运算。相对其他操作来说，字符串解析需要更多的函数调用和内存访问。

上面的文字听起来很不错，不过如果缓存值不再准确了会怎样？虽说静态缓存只在一次请求中有效，这其中仍然存在缓存过期的可能性。在缓存函数内部对缓存数据进行失效处理是很容易的，但是由于缓存变量的作用域限制，会阻止其他函数访问。这意味着，静态缓存的实现还是可能有引入其他问题。

在Drupal 7之前，函数需要自行决定是否暴露失效缓存的途径。有些通过跟踪一个不太优雅的’失效缓存’的参数，不过多数连这个都没有。Druapl 7中加入drupal_static，让函数可以暴露一个可以为其他函数所用的静态变量，这样就可以在函数作用域之外改变这一变量了。

ip_address()函数是个静态缓存的好例子。很多站点具有地理相关的功能（例如把用户重定向到缺省语言或者展示本地内容），这种功能的测试也明显的比较麻烦。Smart IP模块实现了一个测试，用一个IP伪造的Form来测试用户权限和debug变量：

    if (user_access('administer smart_ip') && variable_get('smart_ip_debug', FALSE)) {

        $ip = variable_get('smart_ip_test_ip_address', ip_address());

        $location = smart_ip_get_location($ip);

如何对这个内容进行自动化测试呢？测试账号需要访问权限（阻止匿名用户访问测试函数），IP 地址的变化也会影响到管理员用户。更糟糕的是，每次对测试IP地址的修改都会导致一次variable表的写入，这会拖慢整个站点。

因为ip_address()使用drupal_static()暴露了他的静态缓存，所以就可以修改他的返回值了。这样测试过程就可以测试所有IP相关的函数，而不需要用户账号、权限或者对variable表的访问。要切换回普通的IP Address功能只要调用一次drupal_static_reset()，这将导致ip_address()的下次调用会像初次调用一样。

Drupal.org列出了Drupal 7核心中的180次对drupal_statc()的调用，drupalcontrib.org中报告了563此。并不是每次drupal_static()调用都是静态缓存，也不是每个静态缓存都用drupal_static实现，不过这仍然给我们以灵感，如何通过静态缓存来提高Drupal的性能。

清空主题缓存

Sat, 05 Jul 2014 01:21:46 +0800

原文：Clearing the theme cache

info 文件被缓存在数据库中（不一定是数据库，反正是缓存了——译者注），所以对这个文件的变更，Drupal 是没有感知的。如果你新增了 tpl.php 文件，或者覆盖了新的主题方法，那么你需要清空主题缓存才能让这些变更生效。

不要把这个缓存和主题注册表混淆了。要清理缓存，按照如下步骤进行：

点击Performance页面里的“Clear all caches”按钮。注意这个按钮会清空所有的缓存，其中不只是主题缓存。如果你的站点有很多页面或者很大流量，你可能希望用下面的其他办法只清除主题缓存。
- Drupal 7 “Administration > Configuration > Development > Performance”（admin/config/development/performance）。
- Drupal 6 “Administer > Site configuration > Performance” （admin/settings/performance）。
其他办法：
- Admin menu在Home图标下面有一个清空缓存的按钮。
- Devel project中的Devel Block模块提供了一个”Empty cache”的连接。
- D7中的drupal_theme_rebuild或者D6中的drupal_rebuild_theme_registry API 函数。
- 有些主题（Zen, Fusion等）在每个页面提供了一个复选框来重建主题缓存，带有漂亮的警告来提示你不要忘记关闭这东西。
- Drush提供了一个命令：drush cc theme-registry.
- The Magic Module有一个设置”Rebuild Theme Registry on Page Reload”（在页面重新载入时重建主题注册表）可以用于任何主题。
- 浏览主题选择页也会清空.info文件缓存

如果上面的办法都失败了，还可以尝试清空全部缓存。