想象一下，你刚刚发布了一篇博文，并分享到了社交网络。然后，这篇文章恰巧被大V看中再次分享了出去，立即吸引了数百粉丝的目光，引导他们涌入了你的网站。看到这么多的访客量，以及它们的评论，你内心激动不已。突然之间，你的网站就挂掉了，满屏的数据连接错误……
或者假想另一种情境，你一直很努力地创业。突然有一天，一个大V在社交网络表达了对贵公司的喜爱之情，字里行间满满的赞叹。关注这个大V的粉丝心动了，又涌入了你的网站。不幸的是，点击连接后却无法进入你的网站，或者进入后无法注册用户，甚至页面相应超时，无法获取产品的序列号。尽管你在社交网络上对此非常诚恳的表达了歉意，但众多的浏览者都不会再有兴趣。
这些假想其实非常普遍。在我的工作中，就经常发现，当网站信息在社交网站流传开来的时候，移动设备的访问请求就会骤增。这也表明，在社交网络中，越来越多的人开始使用移动设备，而不是传统的桌面应用。此外，大多数的移动用户都在使用公共 Wi-Fi 以及其他低速网络来访问网站。所以，快速加载网站的任何优化措施，都会有利于用户的访问。
在本文中，我会向你介绍 Varnish 网页应用加速器（Varnish Web application accelerator）——这是一个免费、简单的工具，大大改善大规模突发性访问状态下的响应能力。
对于大多数的网站来说，众多用户请求访问的核心内容大都是一致的——尤其是每天都会更新内容的门户网站。不用多说你也会理解，图片、CSS 和 JavaScript，这些静态资源往往有较长的有效期（译者注：有利于在不同页面间复用）。但你可能没有深入思考过，通常在博客平台或者是内容管理系统中，响应用户的请求后，所返回的数据内容，大多也是相同的。
来自社交网络的用户进入一个博客后，并不会请求完全一致的信息。除了图片、JavaScript 和 CSS，这些信息还包括 PHP 动态生成的内容，以及从数据库查询到的数据。访问博客中的某一篇博文，所需要发送的每一条请求，不仅仅是在获取网络服务器提供的静态资源，还需要配合 PHP 脚本，使用数据库连接以及数据库表单检索等功能。
数据库连接的数量越多，Apache 需要处理的进程就会越多，而总的处理能力是由限度的。相应的，访客的数量越多，服务就会越不稳定，挣到的钱就会越少。
这就是类似 Varnish 的 HTTP 缓存发挥作用的地方。如此一来，从浏览器发出的请求，不再直接到达创建和维护网页的服务器，而是到达 HTTP 缓存服务器。如果缓存服务器中存在所需页面，那么直接从服务器的内存返回相应的资源，不再动用 Apache 服务器和数据库。如果所需页面不再缓存中，那么就像传统方式一样，使用 Apache 服务器来处理。Apche 处理完成之后，就会将这个页面保存到 HTTP 缓存服务器中，等到下一次请求相同页面时就可以直接返回了。
将页面保存在内存中，其响应速度远快于将其保存在硬盘中。此外，当请求的页面为于 HTTP 缓存服务器中时，就无需动用 PHP 或者数据库来处理相关操作。这也让 PHP 和 服务器能够有更多的性能来处理更繁重的进程和连接。比如，上面提到的被大 V 称赞的那家初创公司面临的情境，众多粉丝点击的链接其实只是网站中的少数几个页面——而这些完全可以保存在高速缓存服务器中，当需要时直接从内存响应请求。此时，准备注册的用户就会感到整个流程非常顺利，因为后台脚本和数据库连接的处理能力非常宽裕，完全不受突发性请求的影响。
原理下面这个示意图，展示了 Apache 服务器响应请求后生成站点内容的基本流程。在这个例子中，为了请求相同的页面，一共从浏览器发送了五条指令给 Apache，而 Apache 很呆板的对每条请求都做了详细的处理。
是的，Apache 处理了每一条请求——图像，CSS，JavaScript 和 HTML 文件。如果 PHP 中有某个文件，就会解析一次。如果需要请求数据库的信息，那么就要执行一次数据连接，进行 SQL 查询等操作。最终，在 Apache 返回给浏览器信息之前，数据库返回相关信息组装成完成的页面。
如果我们在 Apache 之间使用 Varnish，我们就可以形成这样的一个流程：
