领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
Facebook创新之BigPipe：优化页面加载时间
作者 Dave West 译者 张龙 发布于 2010年8月1日
近日，Facebook的研究科学家Changhao Jiang介绍了一个名为BigPipe的技术，这项技术可使Facebook站点的访问速度提升一倍。BigPipe是Facebook的创新研究之一，同时也是Facebook的“秘密武器”，它能够极大提升站点的性能：在大多数浏览器中，BigPipe都能将用户感受到的延迟时间降低一半，除了Firefox 3.6，BigPipe可以将Firefox 3.6的延迟时间降低50ms左右，大约降低了22%左右。
BigPipe及相关创新的驱动力是：
相比于10年前，现代Web站点的动态性与交互性都迈上了一个新台阶，传统的页面处理模型已经无法满足当今Internet速度上的需求了。
受到硬件的启发（管道与标量微处理器），Facebook团队使用PHP和JavaScript（并不需要改变现有的Web服务器和浏览器）“重新设计了现有的Web服务处理过程”。重新设计的内容包括：将页面处理过程分解为8个不同的步骤（每个步骤叫做一个“pagelet”），其中一些步骤可以并行处理。通过返回如下内容来响应最初的页面请求：
一个未闭合的HTML文档，包含了HTML head标签和body标签的第一部分内容。head标签包含了BigPipe的JavaScript库，用于解释稍后收到的pagelet响应内容。在body标签中，有个模板指定了页面的逻辑结构和pagelets的占位符。
然后创建JSON编码的对象（即pagelets），里面包含了“pagelet需要的所有CSS、JavaScript资源、HTML内容以及一些元数据”。
复杂网页不断攀升的加载时间延迟问题已经不是什么新话题了，也有不少人提出使用某种管道技术来提升性能。Aaron Hopkins在Die.net上讨论过如何优化页面加载时间，除了传统的页面请求生命周期外，还有不少影响因素可以影响到页面加载的延迟时间。Aaron提到的有趣儿的一点是：
IE、Firefox与Safari默认情况下是禁用管道的；Opera是我所知道的唯一一个启用了管道的浏览器。禁用管道意味着需要应答每个请求，在下一个请求发出前需要释放掉上一个请求所建立的连接。这样就增加了用户等待的延迟时间，平均延迟时间为双向的ping时间除以允许的连接数。如果服务器禁用了HTTP持续连接（keepalives），那么还需要再进行一次TCP三次握手，这又导致一次双向连接，造成延迟时间加倍的后果。
Jiang并没有说BigPipe利用了浏览器所固有的管道功能，实际上却暗示了BigPipe并没有这么做，因为他说不需要对现有的服务器与浏览器进行任何改变。一旦浏览器发生了变化（比如HTML 5的广泛实现），BigPipe创新的用途是否还会这么大，我们不得而知。
Kensaku Komatsu创建了一个示例（The Zinger谈到了该示例）：
... 对HTML5 Web Sockets中的数据流与XML HTTP Request进行了对比。运行结果令人震惊：565毫秒对31444毫秒，天哪！Web Sockets快了55倍，这是因为Web Sockets减少了大量不必要的header信息。
该示例使用了HTTP Pipelining，但通常人们认为这么做有些“危险”：
这并非HTTP Pipelining。网络传输是由WebSocket frames构成的，而非HTTP请求与响应。显然，这是由应用作者控制的，并不会遇到HTTP/1.1管道的问题。由于WebSockets可以在任何时间发送与接收，可以由程序员直接控制，因此它并不会遇到代理干扰（proxy interference）的问题，管道功能是安全的，不应该禁用。
Komatsu的示例将Facebook的创新、HTTP管道问题以及HTML 5的未来有机联系在了一起，尤其是WebSockets以及他们最终该如何交互以提升Web站点的性能并最大限度地降低用户等待的延迟时间。
查看英文原文：BigPipe at Facebook: Optimizing Page Load Time
译者 张龙 热衷于编程，乐于分享，对新技术有强烈的探索欲，对Java轻量级框架有一定研究。
木有看懂
发表人
Cui Guangyu
发表于
有错别字
发表人
冯 希顺
发表于
Re: 有错别字
发表人
张 龙
发表于
Re: 木有看懂
发表人
冯 希顺
发表于
研究科学家
发表人
Shooter Evan
发表于
chunck 和 压缩 怎么权衡，不知facebook有否这方面的实际数据
发表人
杜 嘉伟
发表于
-
木有看懂。 不知道意思是不是说一次请求过来一大堆的字符串或者别的什么， 然后客户端的javascript慢慢构造DOM，构造图片， 构造需要的东西？如果是的话， 似乎不是很新啊。。。
-
“平均延迟时间为双向的ping时间处以允许的连接数。”，这里的“处以”貌似需要变成“除以”。。。
-
这有一篇文章是对Facebook这个技术的分析（好像作者还不知道这个BigPipe技术）：
www.cnblogs.com/BearsTaR/archive/2010/06/18/fac...
我觉得这样还有一个好处是容易做缓存。可能Facebook某个页面是动态的，但是页面中的大部分内容是静态的，如果以整个页面来进行管理就无法进行缓存了，分开就很容易缓存了。 -
多谢，已修复
-
哇塞。。。瞧人家，都不是 “开发工程师”了。。。。研究科学家。。。
-
这样做虽然可以将应答分块供js可以并发处理，但使用chunck技术，就无法压缩传输内容， facebook是怎样权衡这“压缩”和chunck 之间的得失的？
不知facebook有否这方面的实际数据？
6 条回复
关注此讨论 回复