清漆有几个优点。 你注意到的第一个是减less后端服务器上的负载。 通常通过cachingdynamic生成的内容，但很less更改（与访问的频率相比）。 拿你的WordPress的例子来说，大多数页面大概不会经常改变，并且有一些插件可以在页面改变时（例如新的后期，编辑，评论等等）使varnishcaching无效。 因此，您无限期地caching，并在更改时无效 – 这将导致后端服务器的负载最小。

链接的文章不能承受，大多数人会build议清漆比Nginxperformance更好，如果安装正确 – 虽然（我真的很讨厌承认它） – 我自己的testing似乎认为，nginx可以提供一个静态文件比清漆（幸运的是，我不使用清漆的目的）。 我认为问题是，如果你最终使用光油，你已经添加了一个额外的层到你的设置。 通过额外的层传递到后端服务器总是比从后端直接提供服务要慢 – 这就是为什么让Varnishcaching可能会更快 – 您保存一个步骤。 另一个优势是在磁盘前面。 如果你设置清漆使用malloc，你根本不会打到磁盘，这样就可以用于其他进程（通常会加快速度）。

我认为人们需要一个更好的基准来衡量performance。 重复地请求相同的单个文件，触发文件系统caching，开始将焦点从Web服务器本身移开。 一个更好的基准将使用包含几千个随机静态文件（甚至可能来自您的服务器日志）的围攻来模拟真实的stream量。 可以说，正如你所提到的，将静态内容转移到CDN已经变得越来越普遍，这意味着Varnish可能不会在开始时提供它（你提到S3）。

在现实世界中，您可能会优先考虑内存使用情况 – 首先是dynamic内容，因为这是最昂贵的产生; 然后是小的静态内容（例如js / css），最后是图像 – 除非您有足够的理由这么做，否则您可能不会将其他媒体caching在内存中。 在这种情况下，varnish从内存加载文件，nginx从磁盘加载它们，varnish可能会超出nginx（请注意，nginx的caching仅用于代理和fastCGI，而这些默认情况下是基于磁盘的 – 尽pipe可能与memcached一起使用nginx）。

（我的速度 – 非常粗糙，没有任何可信度 – testing显示nginx（直接）是最快的 – 让我们称之为100％，清漆（与malloc）有点慢（约150％），nginx后面的清漆通过）是最慢的（大约250％），这说明了它本身 – 全部或全部 – 加上额外的时间（和处理）与后端进行通信，只是build议如果你正在使用光油，并有RAM备件，你可能只是caching一切你可以从varnish而不是传回nginx。）

我想你可能会错过一些东西。

根据定义，dynamic文件会改变。 通常情况下，他们通过做某种数据库查询来改变，这会影响正在向用户提供的页面内容。 因此，您不想cachingdynamic内容。 如果这样做，它只会变成静态内容，而最有可能的是静态内容不正确。

作为一个简单的例子，假设您的页面顶部有一个login用户名的页面。 每次加载该页面时，都会运行数据库查询以确定login用户所属的用户名，请求该页面以确保显示正确的名称。 如果你要caching这个页面，那么数据库查询就不会发生了，所有的用户都会在页面的顶部看到相同的用户名，这可能不会是他们的用户名。 您需要在每次加载页面时进行查询，以确保向每个用户显示正确的用户名。 因此它不能被caching。

把这个逻辑扩展到更像用户权限的问题，你可以看到为什么dynamic内容不应该被caching。 如果数据库未命中dynamic内容，则CMS无法确定请求页面的用户是否有权查看该页面。

根据定义，静态内容对于所有用户都是相同的。 因此，不需要进行数据库查询来为每个用户定制该页面，所以caching该数据库以消除不必要的数据库查询是有意义的。 图像是静态内容的一个很好的例子 – 你希望所有用户看到相同的头像，相同的loginbutton等，所以它们是非常好的候选caching。

在上面的代码片段中，您会看到一个非常典型的Varnish VCL片段，它强制图像，css和javascript被caching。 默认情况下，Varnish不会caching任何带有cookie的请求。 其逻辑是，如果请求中有一个cookie，那么服务器就需要这个cookie，所以在后端需要它，并且必须通过caching。 实际上，很多CMS（Drupal，Wordpress等）都将cookies附加到几乎所有的东西上，无论它是否被需要，所以通常写VCL从已知是静态的内容中去除cookies，这反过来导致Varnishcaching它。

合理？

对于dynamic内容 ，股票报价等实际情况经常变化（从backend server到SaaS server每秒更新一次），但可能会更频繁地查询（通过成千上万的subscription clients ）：

 [stock calculation / backend server] ----- [SaaS server] ------ [subscription clients] 

在这种情况下，在SaaS server上caching来自backend servers的每秒更新可以满足成千上万的subscription users的查询。

没有在SaaS服务器上的caching，那么这个模型就无法工作。

使用Varnishcaching静态文件将有利于卸载Nginx。 当然，如果你有很多的静态文件要caching，这将浪费RAM。 但是，Varnish具有很好的function – 它支持多个存储后端的caching。

对于静态文件：caching到硬盘其他的一切：caching到内存。

这应该让你更深入的了解如何实现这个场景： http : //www.getpagespeed.com/server-setup/varnish-static-files-cache