如何使用 Varnish 和 Cloudflare 实现最大缓存
本文是关于构建示例应用程序（多图像库博客）以进行性能基准测试和优化的系列文章的一部分。 （在此处查看回购协议。）
正如我们在这份报告中看到的那样，我们网站的登录页面加载速度非常快并且通常得分很高，但它可以使用另一层缓存甚至 CDN 来真正做到这一点。
要了解有关 GTMetrix 和其他可用于测量和调试性能的工具的更多信息，请参阅提高页面加载性能：Pingdom、YSlow 和 GTmetrix。
现在让我们使用我们在之前的 Varnish 帖子中学到的知识，以及在 CDN 和 Cloudflare 帖子中获得的知识来真正调整我们服务器的内容交付。
漆
Varnish 的创建仅仅是为了成为常规服务器前面的一种超级缓存。
注意：鉴于 Nginx 本身已经是一个非常好的服务器，人们通常会选择其中之一，而不是两者。 两者都没有坏处，但是必须警惕可能发生的缓存破坏问题。 正确设置它们很重要，这样其中一个的缓存不会过时，而另一个是新鲜的。 这可能导致在不同的时间向不同的访问者显示不同的内容。 设置它有点超出本文的范围，将在以后的指南中介绍。
我们可以通过执行以下命令来安装 Varnish：
curl -L https://packagecloud.io/varnishcache/varnish5/gpgkey | sudo apt-key add -
sudo apt-get update
sudo apt-get install -y apt-transport-https
当前的 Ubuntu 存储库列表没有可用的 Varnish 5+，因此需要额外的存储库。 如果文件 /etc/apt/sources.list.d/varnishcache_varnish5.list 不存在，创建它。 添加以下内容：
deb https://packagecloud.io/varnishcache/varnish5/ubuntu/ xenial main
deb-src https://packagecloud.io/varnishcache/varnish5/ubuntu/ xenial main
然后，运行：
sudo apt-get update
sudo apt-get install varnish
varnishd -V
结果应该是这样的：
$ varnishd -V
varnishd (varnish-5.2.1 revision 67e562482)
Copyright (c) 2006 Verdens Gang AS
Copyright (c) 2006-2015 Varnish Software AS
然后我们将服务器的默认端口更改为 8080。我们这样做是因为 Varnish 将改为使用端口 80，并根据需要将请求转发到 8080。 如果您按照本系列开头的说明在 Homestead Improved 上进行本地开发，则您需要编辑的文件将位于 /etc/nginx/sites-available/homestead.app. 否则，它可能会在 /etc/nginx/sites-available/default.
server {
listen 8080 default_server;
listen [::]:8080 default_server ipv6only=on;
接下来，我们将通过编辑来配置 Varnish 本身 /etc/default/varnish 并将第一行 (6081) 上的默认端口替换为 80：
DAEMON_OPTS="-a :80
-T localhost:6082
-f /etc/varnish/default.vcl
-S /etc/varnish/secret
-s malloc,256m"
同样需要在 /lib/systemd/system/varnish.service:
ExecStart=/usr/sbin/varnishd -j unix,user=vcache -F -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m
最后，我们可以重启 Varnish 和 Nginx 以使更改生效：
sudo service nginx restart
sudo /etc/init.d/varnish stop
sudo /etc/init.d/varnish start
systemctl daemon-reload
最后一个命令在那里，以便以前编辑的 varnish.service 守护进程设置也会重新加载，否则它只会考虑 /etc/default/varnish 文件的变化。 这 start + stop 程序对于 Varnish 来说是必要的，因为当前的错误不能正确释放端口，除非以这种方式完成。
将结果与上一个结果进行比较，我们可以看到由于着陆页已经进行了极度优化，因此差异很小。
边注
这两个低分主要是我们“没有从一致的 URL 提供服务”的结果，正如 GTMetrix 所说：
发生这种情况是因为我们使用随机图像来填充我们的画廊，并且随机样本很小，所以其中一些是重复的。 这很好，并且在网站投入生产时不会成为问题。 事实上，这是一种非常罕见的情况，站点在默认情况下在生产中的得分比在开发中的得分更高。
云焰
接下来让我们设置 Cloudflare。 首先，我们注册一个账号：
因为 Cloudflare 需要应用一些 DNS 设置，因此需要有一个附加到 IP 地址的域（即没有办法只使用目标服务器的 IP 地址，就像我们目前在测试中所做的那样），我们应该为此目的注册一个演示域。 我有一个旧域名 caimeo.com 我现在可以使用它，但首先，域需要连接到带有 A 记录的 DigitalOcean Droplet 的 IP 地址：
Cloudflare 然后将扫描并复制这些现有记录，如果他们的系统无法识别所有记录，您还可以添加任何缺失的记录。
在此过程结束时，需要更新原始注册商处的域名称服务器，以便它们指向 Cloudflare 的。 此时，Cloudflare 正在为您完全控制您的域（尽管可能需要长达 24 小时才能传播给所有可能的访问者）。
您可以使用 Cloudflare 仪表板查看帐户级别和应用于给定域的设置。
一旦服务激活，我们就可以将新的 GTMetrix 结果与旧的进行比较。
虽然 YSlow 现在对我们的喜爱度增加了 6%，但似乎我们可以做的更多，因为 Cloudflare 集成显然使我们的网站速度降低了 23%。
首先，让我们尝试打开自动缩小（在 Cloudflare 仪表板的速度下）并完全清除缓存（在缓存下）。 然后，我们将在比较之前运行几次测试，以便缓存适当预热。
那更好！ 再运行几次测试可能会使加载时间更接近最初的 1.4 秒，但我们也来看看 CloudFlare 的 Rocket Loader 工具。 它处于测试阶段，通过将它能找到的所有 JavaScript（甚至外部文件）捆绑在一起并异步加载这些文件来工作。 然后它将这些资源缓存在本地浏览器中，而不是从远程服务器重新获取它们。 比较在这里。
可悲的是，这还有一些不足之处。 YSlow 确实更喜欢我们，因为我们缩小得更好并且请求更少，但是这些工具似乎错误地配置了一些以前工作得更好的设置。 让我们将其关闭并清除缓存，之前的设置更好。
其他可能的调整
不要忘记网站图标！
添加网站图标总是一个好主意——更少的 404 请求，它在浏览器中看起来会更好。 此外，瀑布屏幕清楚地告诉我们，在这 1.6 秒中，大约 330 毫秒用于等待图标！
繁荣！ 有了我们的网站图标，我们又缩短了 300 毫秒。
Nginx 调整
您可能是在跳过 Nginx 优化部分后来到这篇文章的。 建议您也应用该技巧中的技巧。 这篇文章中执行的调整实际上已经应用到该网站的实时版本，因此在与该文章不同的服务器上。 Varnish 和 Nginx 在这里串联调整产生更好的结果：
location ~* .(?:ico|css|js|gif|jpe?g|png|/raw)$ {
expires 14d;
}
HTTP/2
考虑使用 Varnish 激活 HTTP/2。 看到瀑布图中的这些阻塞线了吗？
那是因为它们一次被加载几个，而其他的则等待前面的加载完成。 使用 HTTP/2，这个问题就消失了，整个站点加载速度更快，通过同一连接下载多个文件。 一个警告是该站点需要证书。 有了 Let’s Encrypt，现在实现起来非常简单。 另一个警告是您需要重建包含 HTTP/2 模块的 Nginx，因此需要在服务器上进行一些调整。 最后要注意的是，HTTP/2 在 Varnish 上仍处于 beta 支持阶段，可能不应该过于依赖它。
要了解如何配置 Varnish 和 HTTP/2，请参阅本教程。
结论
我们实施了 Varnish 作为附加缓存层，并将 Cloudflare 的免费计划实施为我们的 CDN，从而显着提高了我们的 GTMetrix 分数。 虽然我们的优化过程对于一个如此简单的应用程序来说可能有点矫枉过正，但从第一天起就知道我们的应用程序能够每秒处理数十万用户而不会中断——而且所有这些都在一台 10 美元的服务器上，这让我们感到非常安心。
如果我们遗漏了任何步骤并且您认识到我们可以执行的其他性能技巧，请告诉我们！
