使用 Varnish/ESI 和 Zend 框架缓存和页面视图答案

【问题标题】：Caching and Page Views with Varnish/ESI and Zend Framework使用 Varnish/ESI 和 Zend 框架缓存和页面视图
【发布时间】：2011-11-29 09:26:01
【问题描述】：

我有几个场景，我最终需要在几个月后考虑。只是把问题扔在那里，以便我可以同时考虑讨论。

我将 Zend Framework 用于我的应用程序堆栈。我正在使用 APC 进行服务器缓存（而不是 memcache，因为我不相信 memcache 对我有任何好处，即使我的应用程序是分布式的。）

我的应用程序已经构建为在没有 JavaScript 的情况下工作，然后为了支持 JavaScript，我将页面分解并呈现 JavaScript 友好版本。

如果你分析一个简单的页面，可能 80% 是核心功能，可以为每个用户缓存。然后为该用户定制其中的 20%。例如，我可能想显示

最近查看的 5 个项目
收藏项目

这两个“小部件”将针对每个用户。我正在考虑对这些组件使用 ESI，但后来我发现任何/我的 Zend Framework 应用程序最消耗的方面是引导和调度过程。因此，如果我的应用程序当前需要 80 毫秒而没有缓存。就像 90% 的相对时间花在引导程序和插件挂钩上，如果我要使用 ESI 加载这两个“小部件”，那么我会有效地将负载添加到每个页面？因为我将为每个缓存页面启动另一个 80 毫秒的请求。

在这种情况下，您是否建议只通过 JavaScript 加载自定义的小部件/sn-ps，一旦加载初始页面就可以拉取。这样做的明显好处是，只有一个请求被缓存，然后在初始页面（被缓存）被提供后，任何定制的东西都会被拉入一个请求中。

如果我正在寻找最高性能，这似乎是更好的解决方案？

【问题讨论】：

标签： zend-framework caching varnish esi

【解决方案1】：

您可以构建第二个简单的应用程序，该应用程序基于 ajax 调用从缓存中读取数据，并且仅在信息未缓存时才进行引导。然后可以将响应添加到缓存中，因此进一步的调用不会加载您的 zend 项目。这是一个正常的过程，但也需要对缓存失效进行编程。您已经在使用适合此的 apc。显然它不适用于最近 5 次查看或类似的内容。

【讨论】：

【解决方案2】：

使用 ESI 进行清漆不会帮助您减少页面加载时间，因为知道 80 毫秒已经很好（人类用户不会在 1 和 500 毫秒之间产生任何差异...）

这将帮助您避免因负载过重而造成的服务器压力，并且这对 ESI 和 AJAX 一样有效。

如果您的首要任务是尽快显示主页，AJAX 是最好的方式，因为 ESI 会等待子请求响应，然后再发送整个页面。

如果您仍然希望您的应用不兼容 JS，您可以过滤过滤用户代理以尽可能使用 JS，如果不能使用 ESI，但这种技巧很容易弄脏...

【讨论】：