cloudflare_如何使用清漆和Cloudflare进行最大程度的缓存

cloudflare

This article is part of a series on building a sample application — a multi-image gallery blog — for performance benchmarking and optimizations. (View the repo here.)

本文是构建用于性能基准测试和优化的示例应用程序(一个多图像画廊博客)系列文章的一部分。 (在此处查看回购 。)

---

---

As we can see in this report, our site’s landing page loads very quickly and generally scores well, but it could use another layer of caching and even a CDN to really do well.

正如我们在该报告中看到的那样，我们网站的目标网页加载速度非常快，并且总体上得分不错，但是它可能会使用另一层缓存甚至CDN来实现出色的效果。

To learn more about GTMetrix and other tools you can use to measure and debug performance, see Improving Page Load Performance: Pingdom, YSlow and GTmetrix.

要了解有关GTMetrix和可用于测量和调试性能的其他工具的更多信息，请参阅《 提高页面加载性能：Pingdom，YSlow和GTmetrix》 。

Let’s use what we’ve learned in our previous Varnish post, along with the knowledge gained in the Intro to CDN and Cloudflare posts to really tune up our server’s content delivery now.

让我们使用在上一则Varnish帖子中所学到的知识，以及在CDN简介和Cloudflare帖子中获得的知识，现在可以真正地调整服务器的内容交付。

漆 (Varnish)

Varnish was created solely for the purpose of being a type of super-cache in front of a regular server.

创建Varnish的唯一目的是成为常规服务器之前的一种超级缓存。

Note: Given that Nginx itself is a pretty good server already, people usually opt for one or the other, not both. There’s no harm in having both, but one does have to be wary of cache-busting problems which can occur. It’s important to set them both up properly so that the cache of one of them doesn’t remain stale while the other’s is fresh. This can lead to different content being shown to different visitors at different times. Setting this up is a bit outside the context of this post, and will be covered in a future guide.

注意：鉴于Nginx本身已经是一台非常不错的服务器，人们通常会选择一个或另一个，而不是两者都选。 两者都没有害处，但是必须警惕可能发生的缓存破坏问题。 正确设置它们的位置很重要，以使其中一个的缓存不会陈旧，而另一个的缓存保持新鲜。 这可能导致在不同的时间向不同的访问者显示不同的内容。 进行此设置有点超出本文的范围，并且将在以后的指南中介绍。

We can install Varnish by executing the following:

我们可以通过执行以下操作来安装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

The current list of repos for Ubuntu does not have Varnish 5+ available, so additional repositories are required. If the file /etc/apt/sources.list.d/varnishcache_varnish5.list doesn’t exist, create it. Add to it the following:

当前用于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

Then, run:

然后，运行：

sudo apt-get update
sudo apt-get install varnish
varnishd -V

The result should be something like:

结果应该是这样的：

$ varnishd -V
varnishd (varnish-5.2.1 revision 67e562482)
Copyright (c) 2006 Verdens Gang AS
Copyright (c) 2006-2015 Varnish Software AS

We then change the server’s default port to 8080. We’re doing this because Varnish will be sitting on port 80 instead, and forwarding requests to 8080 as needed. If you’re developing locally on Homestead Improved as instructed at the beginning of this series, the file you need to edit will be in /etc/nginx/sites-available/homestead.app. Otherwise, it’ll probably be in /etc/nginx/sites-available/default.

然后，我们将服务器的默认端口更改为8080。我们这样做是因为Varnish将改为位于端口80上，并根据需要将请求转发到8080。 如果您按照本系列开始时的指示在Homestead Improvement上进行本地开发，则需要编辑的文件将位于/etc/nginx/sites-available/homestead.app 。 否则，它可能位于/etc/nginx/sites-available/default 。

server {
    listen 8080 default_server;
    listen [::]:8080 default_server ipv6only=on;

Next up, we’ll configure Varnish itself by editing /etc/default/varnish and replacing the default port on the first line (6081) with 80:

接下来，我们将通过编辑/etc/default/varnish并将第一行中的默认端口(6081)替换为80来配置Varnish：

DAEMON_OPTS="-a :80 \
   -T localhost:6082 \
   -f /etc/varnish/default.vcl \
   -S /etc/varnish/secret \
   -s malloc,256m"

The same needs to be done in /lib/systemd/system/varnish.service:

同样需要在/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

Finally, we can restart both Varnish and Nginx for the changes to take effect:

最后，我们可以重新启动Varnish和Nginx，以使更改生效：

sudo service nginx restart
sudo /etc/init.d/varnish stop
sudo /etc/init.d/varnish start
systemctl daemon-reload

The last command is there so that the previously edited varnish.service daemon settings also reload, otherwise it’ll only take into account the /etc/default/varnish file’s changes. The start + stop procedure is necessary for Varnish because of a current bug which doesn’t release ports properly unless done this way.

最后一条命令在那里，因此先前编辑的varnish.service守护程序设置也将重新加载，否则它将仅考虑/etc/default/varnish文件的更改。 Varnish的start + stop过程是必需的，因为当前的bug除非这样做，否则无法正确释放端口。

Comparing the result with the previous one, we can see that the difference is minimal due to the landing page already being extremely optimized.

将结果与上一个结果进行比较，我们可以看到差异很小，这是因为登录页面已经过优化。

边注 (Sidenote)

Both of the low grades are mainly the result of us “not serving from a consistent URL”, as GTMetrix would put it:

GTMetrix会这样说，这两个较低的等级主要是我们“未从一致的URL提供服务”的结果：

This happens because we used random images to populate our galleries, and the sample of randomness was small, so some of them are repeated. This is fine and won’t be an issue when the site is in production. In fact, this is one of the very rare cases where a site will by default score better in production than it does in development.

发生这种情况是因为我们使用随机图像来填充我们的画廊，并且随机性样本很小，所以其中一些是重复的。 很好，当网站投入生产时不会有问题。 实际上，这是非常罕见的情况之一，默认情况下，网站在生产中的得分要比在开发中的得分高。

云耀斑 (Cloudflare)

Let’s set up Cloudflare next. First, we register for an account:

接下来让我们设置Cloudflare。 首先，我们注册一个帐户：

Because Cloudflare needs some DNS settings applied and thus requires there to be a domain attached to an IP address (i.e. there’s no way to use just an IP address of the destination server, like we’re doing in the tests so far), we should register a demo domain for this purpose. I have an old domain caimeo.com which I can use for this at this time, but first, the domain needs to be connected to the IP address of the DigitalOcean droplet with an A record:

由于Cloudflare需要应用一些DNS设置，因此需要将一个域附加到IP地址(即，到目前为止，就像我们在测试中一样，无法使用目标服务器的IP地址)，我们应该为此注册一个演示域。 我有一个旧域名caimeo.com ，目前可以在其中使用该域名，但是首先，该域名需要连接到带有A记录的DigitalOcean Droplet的IP地址：

Cloudflare will then scan and copy these existing records, allowing you to also add any missing ones if their system failed to identify them all.

然后，Cloudflare将扫描并复制这些现有记录，如果它们的系统无法完全识别所有丢失的记录，您还可以添加任何丢失的记录。

At the end of the process, the domain’s nameservers over at the original registrar need to be updated so that they point to Cloudflare’s. At this point, Cloudflare is fully controlling your domain for you (though it may take up to 24 hours to propagate to all possible visitors).

在此过程结束时，需要更新原始注册商处的域名称服务器，以便它们指向Cloudflare的名称服务器。 此时，Cloudflare会为您完全控制您的域(尽管可能需要24小时才能传播到所有可能的访问者)。

You can use the Cloudflare dashboard to see the account level and the settings applied to the given domain.

您可以使用Cloudflare仪表板查看帐户级别和应用于给定域的设置。

Once the service is active, we can compare the new GTMetrix result to the old one.

服务启用后，我们可以将新的GTMetrix结果与旧的结果进行比较。

While YSlow does like us 6% more now, it seems like there’s more we could do since Cloudflare integration apparently slowed our site down by a whopping 23%.

尽管YSlow现在喜欢我们的速度增加了6％，但由于Cloudflare集成显然使我们的网站速度降低了23％，因此我们似乎还有更多可以做的事情。

First, let’s try turning on auto-minification (under Speed in the Cloudflare Dashboard) and fully purging the cache (under Caching). Then, we’ll run the test a few times before comparing, so the cache properly warms up.

首先，让我们尝试启用自动最小化(在Cloudflare仪表板中的“速度”下)并完全清除缓存(在“缓存”下)。 然后，在比较之前，我们将运行几次测试，以使缓存正确预热。

That’s better! A few more test runs would likely get that even closer to the original 1.4s of load time, but let’s also take a look at CloudFlare’s Rocket Loader tool. It’s in beta and works by bundling together all the JavaScript it can find — even external files — and asynchronously loading these files. It then caches these resources locally, in the browser, rather than re-fetch them from a remote server. Comparison here.

那更好！ 再进行几次测试可能会更接近原始的1.4s加载时间，但让我们来看看CloudFlare的Rocket Loader工具。 它处于beta版本，通过捆绑它可以找到的所有JavaScript(甚至是外部文件)并异步加载这些文件来工作。 然后，它将这些资源本地缓存在浏览器中，而不是从远程服务器重新获取它们。 比较这里 。

Sadly, this leaves something to be desired. YSlow does like us more because we minify better and have fewer requests, but the tools seem to be misconfiguring some settings that worked much better previously. Let’s turn it back off and purge cache, the previous setting was better.

可悲的是，这还有些不足。 YSlow确实更喜欢我们，因为我们可以更好地进行精简，减少请求，但是这些工具似乎误配置了一些以前工作得更好的设置。 让我们关闭它并清除缓存，以前的设置更好。

其他可能的调整 (Other Possible Tweaks)

不要忘记收藏夹图标！ (Don’t forget the favicon!)

Adding a favicon is always a good idea — fewer 404 requests and it’ll look better in the browser. Besides, the waterfall screen clearly tells us that of those 1.6s around 330ms is spent waiting for the favicon!

添加收藏夹图标总是一个好主意-较少的404请求，在浏览器中看起来会更好。 此外，瀑布屏幕清楚地告诉我们，在等待屏幕图标时大约花费了330ms的1.6秒！

Boom! With our favicon in place, we shaved off another 300ms.

繁荣！ 凭借我们在地方的小图标，我们剃掉了另一个300毫秒。

Nginx调整 (Nginx tweaks)

You may have come to this post after skipping the Nginx optimization one. It’s recommended you apply the tips from that one as well. The tweaks executed in this post have actually been applied on a live version of the site, so on a server different than one from that post. Varnish and Nginx tweaked in tandem here produce even better results:

您可能在跳过Nginx优化之一之后来了这篇文章。 建议您也应用该技巧中的技巧。 这篇文章中执行的调整实际上已应用于网站的实时版本，因此该服务器与该文章中的服务器不同。 串联调整的Varnish和Nginx产生更好的结果：

location ~* \.(?:ico|css|js|gif|jpe?g|png|/raw)$ {
    expires 14d;
}

HTTP / 2 (HTTP/2)

Consider activating HTTP/2 with Varnish. See these blocking lines in the waterfall chart?

考虑使用Varnish激活HTTP / 2。 在瀑布图中看到这些障碍线吗？

That’s because they’re being loaded a few at a time and the others wait for the previous ones to finish loading. With HTTP/2 that problem disappears, and the whole site loads much faster downloading several files over the same connection. One caveat is that the site requires a certificate. With Let’s Encrypt, that’s very simple to implement these days. Another caveat is that you need to rebuild Nginx with the HTTP/2 module included, so some fiddling around on the server is needed. The final caveat is that HTTP/2 is still in beta support on Varnish, and probably shouldn’t be too relied on.

那是因为它们一次只能加载几个，而其他的则等待先前的加载完成。 使用HTTP / 2，该问题消失了，整个站点的加载速度更快，可以通过同一连接下载多个文件。 一个警告是该站点需要证书。 使用Let's Encrypt ，这几天实现起来非常简单。 另一个警告是，您需要使用随附的HTTP / 2模块来重建Nginx，因此需要在服务器上摆弄一些东西。 最后要说明的是，HTTP / 2在Varnish上仍处于beta支持中，可能不应过于依赖它。

To see how to configure Varnish and HTTP/2, see this tutorial.

要了解如何配置Varnish和HTTP / 2，请参阅本教程 。

结论 (Conclusion)

We implemented Varnish as an additional caching layer, and Cloudflare’s free plan as our CDN, thereby increasing our GTMetrix score dramatically. While our optimization process may have been slight overkill for an app this simple, it’s very reassuring to know from day one that our app is capable of handling hundreds of thousands of users per second without breaking — and all that on a single $10 server.

我们实现了Varnish作为额外的缓存层，而Cloudflare的免费计划成为了我们的CDN，从而大大提高了我们的GTMetrix得分。 尽管对于这样一个简单的应用程序，我们的优化过程可能有些过大，但令人振奋的是，从一开始就知道我们的应用程序能够每秒处理成千上万的用户而不会中断-并在一台10美元的服务器上实现所有这些。

If we’ve missed any steps and you recognize additional performance tricks we could do, please let us know!

如果我们错过了任何步骤，并且您认识到我们可以做的其他性能技巧，请告诉我们！

翻译自: https://www.sitepoint.com/how-to-use-varnish-and-cloudflare-for-maximum-caching/

cloudflare