1

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

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

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

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

  • 最后 5 个查看的项目
  • 收藏品

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

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

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

4

2 回答 2

1

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

于 2012-11-07T04:22:43.700 回答
0

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

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

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

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

于 2011-12-01T17:47:36.593 回答