每个对 Web 应用程序性能感兴趣的人都知道 Facebook's BigPipe 背后的想法。
最近，Symfony 发布了一个新功能，称为fragments sub-framework。
此功能的想法是使用 ESI 技术，W3C 将其描述为ESI Language Specification 1.0。
我的问题是：Facebook 的 BigPipe 是否与这种 ESI 技术相关？我可以使用 ESI 实现 BigPipe 的想法吗？
【问题讨论】：
标签： facebook performance web-applications symfony esi
如果没有您自己的 ESI 服务器实现，可能并非如此，即便如此，是否值得对性能造成影响也是值得怀疑的。
假设我正确理解 BigPipe 文章，所有服务器端所要做的就是 a) 立即将一些静态 HTML 内容刷新到客户端 b) 异步启动一些渲染线程并在线程完成渲染时刷新输出.其余的是 javascript 魔术，与服务器端框架无关。
Symfony 能够呈现一个简单的 HTML 文档并在其中包含 ESI 标记，因此涵盖了 a)。但是 ESI 取决于遇到标签的顺序。这意味着虽然我认为大多数缓存服务器将开始异步处理所有 ESI 标记，但它们只能以特定顺序刷新输出。反过来，这意味着如果您的第一个 ESI 标记很慢，它将阻止任何其他“pagelet”被刷新给用户。
这就是为什么我认为您需要一种特殊类型的缓存服务器，它可以异步获取包含内容，而完全忽略它们出现在文档中的位置。
另一个主要缺点是每个 ESI 标签都会导致它自己的 HTTP 请求到 symfony，这对每个请求都有相当大的设置开销。
总结：如果您想返回一个高速缓存的页面，该页面的生成成本很高，并且包含少量不可缓存的内容，那么 ESI 非常棒，但它可能不适合实现 BigPipe。
【讨论】：