时间戳

首页 > 解决方案 > Varnish 和 WordPress，没有外部插件是否有可能实现真正的缓存？

varnish - Varnish 和 WordPress，没有外部插件是否有可能实现真正的缓存？

问题描述

也许这在 Varnish Cache 世界中听起来是一个新手问题，但为什么在 WordPress 中似乎需要安装一个外部缓存插件才能完全缓存？

网站通过 Varnish 正确加载，一个 curl -I 命令：

HTTP/1.1 200 OK
Server: nginx/1.11.12
Date: Thu, 11 Oct 2018 09:39:07 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Cache-Control: max-age=0, public
Expires: Thu, 11 Oct 2018 09:39:07 GMT
Vary: Accept-Encoding
X-Varnish: 19575855
Age: 0
Via: 1.1 varnish-v4
X-Cache: MISS
Accept-Ranges: bytes
Pragma: public
Cache-Control: public
Vary: Accept-Encoding

使用此配置，默认情况下不会缓存 WordPress 安装。在测试了多个缓存插件之后——有些不工作，或者没有复杂的配置就不能工作——我发现了 Swift Performance，在他们的 Lite 版本中，只需激活 Cache 选项，这里真的充分利用了所有的优势，在这里我可以看到 varnish 与非常在压力测试中取得了不错的成绩。

这对于单个环境中的单个站点可能没问题，但在共享托管方面，当每个客户都可以拥有自己的 WP（或其他 CMS）安装时可能会出现问题。

所以关键是如果不安装第 3 方缓存（和复杂）插件，就无法充分利用 Varnish 的缓存优势？为什么不默认缓存所有？

任何形式的建议和帮助都将受到高度欢迎，在此先感谢。

标签： varnish

解决方案

使用此配置，默认情况下不会缓存 WordPress 安装

默认情况下，如果您在 Wordpress 或 Varnish 配置中都没有更改任何内容，那么一切都会以 Wordpress 页面缓存120 秒的方式协同工作。所以真正的缓存是可能的，但它会是一个短暂的缓存并且非常无效。

您的特定标头表明不应发生缓存。它们要么是由 Varnish 本身发送的（我们都犯了复制粘贴的罪，而不考虑它的作用），要么是 Wordpress 插件（通常是坏的，而不是好的）。在不知道您的具体配置的情况下，很难破译任何东西。

Varnish 是一个透明的 HTTP 缓存代理。这意味着默认情况下，它只会使用由后端（Wordpress）发送的 HTTP 标头来Cache-Control决定是否可以缓存资源以及缓存多长时间。

POST事实上，除了一些特定区域（错误页面、登录提交等）之外，Wordpress 不会发送与缓存相关的标头。

此处概述的标准方法是使用最高 TTL 配置 Varnish。接着就，随即：

Varnish 不知道您何时更新文章内容或更改主题。典型的解决方案是使用缓存失效插件，如 Varnish HTTP Purge。

当内容发生变化时，插件需求来自于清除缓存的必要性。

假设您更新了一个 Wordpress 页面的文本。您之前访问过相同的页面，它进入 Varnish 缓存进行存储。下次访问时会发生什么，Varnish 将为所有下一次访问者提供相同的、现在陈旧的内容。

Varnish 的 Wordpress 插件，如 Varnish HTTP Purge，将连接到 Wordpress，它们将指示 Varnish 在页面更新时清除缓存。这是他们的主要目的。

这种方法（高 TTL 和缓存清除）是 Varnish 的事实上的标准。由于 Varnish 没有关于何时更新内容的信息，因此清除缓存的内部工作与应用程序本身有关。缓存清除功能或者捆绑到 CMS 代码本身（例如 Magento 2，它是开箱即用的，没有任何额外的插件），或者是 Wordpress 插件。

推荐阅读