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