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