velocity china侧记

velocity的2天会议很快就结束了。

大家都围绕着wpo(web performance optimization)分享了很多。

web性能优化总的来说是分前端和后端,但是steve souders告诉我们前端的优化更重要,于是近些年大家围绕着前端做了很多优化,各种前端优化的工具也非常多,有chrome web development tool, speed tracer for firebug, yslow等等工具都是告诉我们如何优化的。以及这次的perload,no-locked js下载等等。

国内很多公司也在前端优化上投入了很多,但是想法都比较老套。比如腾讯现在正在使用的在域名前面带上用户地域等等,这些我在视频网站的时候早就已经这样做了,当时还能细化到各个城市。而CDN也是比较老的东西,大家比拼的其实都是IP列表的精准度和有钱程度,看你能否多布机房和带宽。

基本国内分享的公司就讲个大的概念,什么实时调度阿,什么定制服务器,定制read参数等等。基本上不是不透露技术细节,就是很多公司根本没法实现。

而facebook的2位老兄david wei和changhao jiang分享的东西还是很不错的,细节到位,基本上谁都可以在技术上进行实施的。而另外一个原则就是wpo必须要由一个专门的团队来做,而不是各个业务线自己去完成。不过这个在国内似乎很难实现,因为基本上每个部门都喜欢抢权,有权有的捞啊,这个原则无论在官场还是商场,这种中国特色文化还是非常一致的。

还是来点实际的东西。changhao jiang主要分享了3个技术: quickling, pagecache和bigpipe。提出了一个概念 TTI(time to ineract)通俗的说法就是首屏展现时间,而在首屏展现中我们其实也是有先后的。

quickling技术:这个技术的前提是,当我们从一个页面点击进入到另外一个页面的时候,会有很多重复的东西,而这些东西其实根本不需要重新渲染和下载的,于是quickling通过ajax在页面过度的时候只生成下一个页面新的内容,而不像平常那种,清空所有DOM然后所有重新生成和渲染。我想这个技术应该是特别适合web2.0的很多网站。

pagecache: 大家都知道网页和静态文件是有缓存的,但是当一个静态文件在服务器端更新后,如果是关闭浏览器或者使用F5进行刷新的话会浏览器会发送一个304请求进行校验,如果etag这些不一致的话浏览器会重新进行下载。而当用户在浏览器中来回点击,却只会使用本地缓存而不进行304的校验请求。于是pagecache技术就是通过ajax实现了实时更新缓存,保证了缓存的一致性。举个例子就是:当用户在facebook首页中通过了系统推荐的人,然后他又看了其它页面,而当他再返回到首页的时候系统就会重新更新本地缓存,这样前面给你推荐的那个用户就不会再次被推荐了。这个问题在国内一般的实现是在页面中加个no-cache头,实时生成产生的。而facebook是有缓存的,只有当你进行了相关操作后才会给你更新缓存,这样就降低系统的负载压力。

bigpipe:中文叫流水线。大家都知道浏览器在下载js的时候是以阻塞性的形式进行下载的,等于其它线程都是空闲着的。而facebook的bigpipe技术就会让浏览器并行的下载资源文件。当然这个一开始还是要阻塞式的下载一个pipe.js文件,但是之后的都开始并行的下载并进行渲染了。

作者在说这3个技术的时候还进行一定的演示和比较。这个是非常不错的。而且至少对我来说这些技术都是比较新鲜的,至少我之前都没听说过。PDF下载地址:http://velocity.oreilly.com.cn/ppts/ChanghaoJiang.pdf

David wei分享了2个主题:静态网页资源的管理和优化和一个可持续发展的高性能网站。

对于一个大型网站,静态资源会有非常非常多,涉及到不同语言,不同浏览器,不同地区,非典型性页面等等,还有一些针对不同用户进行定制。而facebook的管理经验是一切都是集中化进行管理。而我当初在sns的经验是各个产品自己管理自己的。

facebook建立了一个static resource manage system。而所有动态Php程序员只需要一次申请在程序中通过管理平台的API进行申请静态资源,而这一次申请后,其它具体使用那个css还是js都是通过这个管理平台来进行了。

这个管理平台分为SR BACKEND和SR FRONTEND。后端主要负责进行依赖分析,本地化和最小化最后把这些文件进行打包或分割。最后把相关的静态资源推送到CDN或者SR前端。后端推送到前端的组件会转换成URI,而URI加上user profile就可以计算出使用哪些静态资源文件,最后再进行异步的加载和打包。

这就是这个系统全部需要完成的工作。而前端这部分就使用到了类似xnix系统的make方法,针对不同的平台,不同的user profile进行make。这还是一个挺绝的想法。而最后的打包工作就使用了相对比较笨的方法,统计出所有页面中使用到的静态资源,然后根据这个进行打包。当然这算是半手工的方式。

david最后还有case study。真是太给力了。这比盛大,百度这些夸夸奇谈好多了。按我的想法,有料的公司才不怕爆料呢,而无料的公司才喜欢夸夸奇谈。这个PDF的下载地址: http://velocity.oreilly.com.cn/ppts/StaticResource2010VelocityChinaDavidWei.pdf 我觉得大家还是应该看视频,那样更完整。

david今天早上还分享了一个《一个可持续的高性能网站》, sns网站的变化是非常快的,这个之前在某SNS网站工作的时候就深刻的感受到了。基本上是每天都更新,而每周还会有一次大的改进。

首先要让大家树立好网站访问速度也是产品的一个特性。于是08年facebook成了PREF SWAT小组,专门抓了20个高手狠抓网站性能问题。之后就一直有小组来负责网站性能的问题。

产品开发时候以性能为导向。主要的流程如下: 首先在一个很好的系统架构上进行开发,然后对系统架构进行测量,测量完成后进行分析数据,分析完数据再进行改进,改进完成后再进行一个循环。

其中提出一个很重要的思想: only one way to do a thing. 因为只有一个选择,那程序员只能选择这个方法去引用静态资源了,那对于网站是非常有好处的。其实这个也是非常符合行为经济学原理的。通常情况下使用唯一的方法往往比有很多方法选择会有更高的效率。

最后就是我们要把影响系统性能这些部分的主导权抓到自己的手中,当然老外都喜欢这样,可国内就麻烦了。

好了,今天就粗略的写到这里,明日后日会对这3个topic进行详细说明。这次velocity还是这3个ppt最给力。 steve souders的topic太高了,而不是一线的经验。

###########################################

Best regards
Timo Seven
blog: http://zauc.wordpress.com
()
Linux System Admin & MySQL DBA