我有一个运行nginx / php-fpm /清漆/ wordpress和Amazon s3的系统。

现在，在设置系统时，我查看了许多配置文件，在所有文件中，我都发现了以下内容：

    /* If the request is for pictures, javascript, css, etc */
    if (req.url ~ "\.(jpg|jpeg|png|gif|css|js)$") {
        /* Remove the cookie and make the request static */
        unset req.http.cookie;
        return (lookup);
    }

我不明白为什么要这么做。大多数示例还将NginX作为Web服务器运行。现在的问题是，为什么要使用清漆缓存来缓存这些静态文件。

仅缓存动态文件对我来说更有意义，这样php-fpm / mysql不会受到太大影响。

我是正确的还是我在这里错过了什么吗？

更新

我想根据给出的答案向问题中添加一些信息。

如果您拥有一个动态网站，其内容实际上发生了很大变化，那么同步就没有意义。但是，例如，如果您将WordPress用于静态网站，则可以将其缓存很长时间。

也就是说，对我来说更重要的是静态内容。我在不同的缓存应用程序和Web服务器应用程序上找到了一些测试和基准的链接。

http://nbonvin.wordpress.com/2011/03/14/apache-vs-nginx-vs-varnish-vs-gwan/

NginX实际上可以更快地获取静态内容，因此让它通过更有意义。NginX非常适合静态文件。

-

除此之外，大多数时候静态内容甚至不在Web服务器本身中。大多数情况下，此内容存储在CDN上某个地方，例如AWS S3之类。我认为清漆缓存是您要存储静态内容的最后一个地方。

Varnish有一些优点。您注意到的第一个是减少后端服务器上的负载。通常，通过缓存动态生成但很少更改的内容（与访问频率相比）。以您的Wordpress为例，大多数页面大概不会经常更改，并且有一些插件可以在页面更改时使清漆缓存无效（例如，新帖，编辑，评论等）。因此，您将无限期缓存，并且在更改时无效-这将使后端服务器的负载最小。

尽管有链接文章，但大多数人会建议如果设置正确，Varnish的性能要比Nginx好-尽管，（我真的不愿承认）-我自己的测试似乎同意，nginx可以比varnish更快地提供静态文件（幸运的是，我没有为此目的使用清漆）。我认为问题在于，如果最终使用Varnish，则会在设置中添加额外的一层。通过该额外的层传递到后端服务器总是比直接从后端提供服务要慢-这就是为什么允许Varnish缓存可能更快的原因-您节省了一步。另一个优点是在disk-io前端。如果您将varnish设置为使用malloc，则根本不会打磁盘，从而使其可用于其他进程（通常会加快处理速度）。

我认为，需要一个更好的基准来真正衡量性能。反复请求相同的单个文件，将触发文件系统缓存，这些缓存开始将焦点从Web服务器本身移开。更好的基准测试可以使用围攻和几千个随机静态文件（甚至可能来自服务器日志）来模拟实际流量。但是，正如您提到的，可以说，将静态内容卸载到CDN变得越来越普遍，这意味着Varnish可能一开始就不会提供它（您提到了S3）。

在现实世界中，您可能会优先考虑内存使用情况-动态内容优先，因为动态内容生成成本最高；然后是小的静态内容（例如js / css），最后是图像-除非确实有充分的理由，否则您可能不会在内存中缓存其他媒体。在这种情况下，如果Varnish从内存加载文件，而nginx从磁盘加载文件，则Varnish的性能可能会超过nginx（请注意，nginx的缓存仅用于代理和fastCGI，而默认情况下，这些缓存是基于磁盘的，尽管可以将nginx与memcached结合使用）。

（我的快速-非常粗略，没有任何信誉-测试显示nginx（直接）是最快的-可以称之为100％，清漆（使用malloc）要慢一些（大约150％），nginx落后于清漆（ （通过）是最慢的（大约250％），这本身就说明了-要么全部完成，要么不执行任何操作-增加了与后端通信的额外时间（和处理时间），只是表明如果您使用的是Varnish，并且要保留RAM ，您最好也可以缓存所有内容并从Varnish提供服务，而不是传递回nginx。）

我认为您可能会缺少一些东西。

根据定义，动态文件会更改。通常，它们通过执行某种数据库查询来更改，这些查询会影响正在提供给用户的页面的内容。因此，您不想缓存动态内容。如果这样做，它将变成静态内容，并且很可能是带有错误内容的静态内容。

举一个简单的例子，假设您有一个页面，页面顶部是登录用户的用户名。每次加载该页面时，都会运行数据库查询以确定哪个用户名属于请求该页面的登录用户，以确保显示正确的名称。如果要缓存此页面，则不会发生数据库查询，并且所有用户都将在页面顶部看到相同的用户名，并且可能不是他们的用户名。您需要在每次页面加载时执行该查询，以确保向每个用户显示正确的用户名。因此，它不可缓存。

将该逻辑扩展到诸如用户权限之类的问题上，您可以看到为什么不应该缓存动态内容的原因。如果没有为动态内容命中数据库，则CMS无法确定请求该页面的用户是否有权查看该页面。

根据定义，静态内容对所有用户而言都是相同的。因此，无需进行数据库查询即可为每个用户自定义该页面，因此可以缓存该信息以消除不必要的数据库查询。图像是静态内容的一个很好的例子-您希望所有用户看到相同的标题图像，相同的登录按钮等，因此它们是缓存的极佳选择。

在上面的代码段中，您会看到一个非常典型的Varnish VCL代码段，该代码段强制图像，css和javascript进行缓存。默认情况下，Varnish不会缓存其中包含cookie的任何请求。逻辑是，如果请求中包含cookie，则必须出于某种原因服务器需要该cookie，因此后端需要它，并且必须将其通过缓存。实际上，无论是否需要，许多CMS（Drupal，Wordpress等）都会将Cookie附加到几乎所有内容上，因此通常编写VCL将Cookie剥离已知为静态的内容，从而导致Varnish缓存它。

合理？

对于动态内容，诸如股票报价之类的某种东西实际上经常更改（SaaS server从a 每秒更新一次backend server），但可能会被更频繁地查询（成千上万次subscription clients）：

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

在这种情况下，对每秒更新从进行缓存可以满足成千上万个查询。SaaS serverbackend serverssubscription users

如果SaaS服务器上没有缓存，则此模型将无法工作。

使用Varnish缓存静态文件将有利于卸载Nginx。当然，如果要缓存大量静态文件，则会浪费RAM。但是，Varnish具有一个不错的功能-它支持其缓存的多个存储后端。

对于静态文件：缓存到HDD对于其他所有文件：缓存到RAM。

这应该使您对如何实现此方案有更多的了解：http : //www.getpagespeed.com/server-setup/varnish-static-files-cache