December 2011

velocity 2011

总的来说,有点失望,含金量不高。

老外的好几个都是在卖广告。。。门票的大头就是他们吧。。。还有一些是说自己的产品如何好如何好,连技术原理都不说,就说你使用了我们的产品呢,能怎么样怎么样的。

简单理一下我的一些笔记吧。略去广告。

======================

第一天,含金量最高,而且都在下午。

Steve Souders 的《高性能移动互联网》。这个Steve 大有来历,简单用熟悉一点的东西去介绍,就是 Yslow 和 Firebug 的开创者。可惜。。。我迟到了。。。前面那部分没听到。后面大概就是说一些与移动互联网相关的参数,Yahoo! 的14 条铁律在移动互联网已经不再完全适用,更多的是依靠app 自身,例如cache 。

章文嵩的《低功耗服务器定制与绿色计算》。上一年SACC 上分享淘宝CDN 的时候就已经提及的话题,今年就展开来说一下。大概就是,在最外层的squid cache 层,cpu 完全不是瓶颈,磁盘IO 和网络IO 才是,在这些地方用低功耗服务器可以节省很大一笔钱呢。然后我惊奇地发现,他们在定制低功耗服务器中测试过的三款CPU ,其中两个intel E5620 和 Atom D525 都是我们正在用或者将会试用的cpu。到现在,他们已经优化到cpu 快成为瓶颈了,真可怕。除了低功耗服务器,淘宝CDN 他就简单带过了,无非就是上一年的内容。混合使用各类不同的磁盘再次提到,无非就是SAS , SATA , SSD 三种不同成本的硬盘用来存放大中小文件,及冷热数据。然后我发现。。。他每次的ppt 介绍的都是这些内容啊。。。是不是每次分享都是一两年前的东西。。。现在内部用的已经是很成熟的一套了??

Percona 的季海东(http://www.haidongji.com/ )的《Innodb/Xtradb 性能优化与诊断》。他喜欢配合着DEMO 来说ppt ,这个其实很好。。。但是当时间不足的时候。。。他连Xtradb 都完全没有提及就已经没有时间了。其中演示了一些MySQL 的操作,技巧等。。。重点的调优说得不多,尤其是,innodb 的最重要参数 buffer_pool_size ,竟然武断地说,一般设置为物理内存的80% 。。。没有考虑到NUMA 架构的机器??

米聊陈臻的《开源工具选型》。这个分享其实不错。米聊同样是一年左右的创业时间,但他们在开源软件的经验上,对比我们还是多了不少。由于他们也是创业公司,注重点还是在产品上面,所以一般都是用开源软件。他们的原则:用大公司正在用的工具,用大公司不用但自己能在代码层级搞掂的工具。他们对于一些软件的选型,其实也没有太多的道理,例如java 容器的选型,resin 和tomcat ,没什么原因,因为初始的那一批人就是用resin 的,而且也没什么毛病,就一直选用resin 了。

奇异李刚的《NoSQL 选型与实践》。也蛮不错的,虽然Sean 一直不推荐去听这个分享@@ 奇异用mongodb 相对于redis 多一点,他们甚至用mongodb 来存放图片。。。这个我实在不能理解。。。不过既然他们用了,而且用得挺欢,那也就参考一下吧。或者是有点数量级了吧,他们对细节的优化很到位,没办法,mongodb 对内存是很贪婪的,他们不优化不行。他们在使用中发现了一些bug ,还主动hack 了。

淘宝的tengine 。其实这个也是不错的。包括两部分,第一部分是朱照远说说淘宝正在如何使用nginx 和tengine 的一些特性吧。第二部分是chaoslawful 的分享,其实就是这个ppt :https://docs.google.com/present/view?id=dddqrph4_23gmctkmcg&pli=1 。tengine 的很多特性还是挺不错的,但是不知道为啥。。。就是不想用。。。唉。。。难道是洁癖作怪??我之前一直徘徊于nginx module 和 nginx_lua 之间挣扎,听完chaoslawful 的分享,不矛盾了,luajit 完胜啊!

第二天,早上第一场据说已经很少人去听了。。。我前一天晚上工作到3 点多,也没能起来。。。也就算了。。。迟到吧

整个早上。。。也是要工作的。。。结果错过了几个分享,只听到半个分享,就是 来自OmniTI 的 Theo Schlossnagle 的运维生涯。分享了一些有趣的故事吧,由于我进场的时候已经说到一半了,就不用同声传译了,直接英语听力吧,所以一些地方可能没有catch 到他的本意。facebook 的infrastructure team 与业务没有关系,专门从事架构类的一些工作,而且还是允许错误发生的,不过不能在同一个错误上犯错两次而已。也说到了所谓的 DevOps ,不过我认为,如果不懂开发的运维,就会沦为操作者,使用着一些别人开发好的工具,严格依照着操作文档去操作而已,在腾讯,叫做一线运维,地位是比较低下的。所以一个合格的运维必须一定懂编程。

百度的《大规模集群控制系统与自动运维》。意义不大,其实就是自己开发的一套运维系统嘛。与sohu 的sagent 差不多,各自都根据自己的业务自己完全开发了一套。其实原理就那些,实现细节虽然可能会麻烦,但也就那些,重点还是有没有人力去做这回事。在我当前无法做到的情况下,我只能用用开源的puppet 了。所以这个分享我听了一半就去听 Yahoo! 的《大型网站性能监控、测量和故障排除》

Yahoo! 的是一个可爱的mm 分享的,主要介绍了yslow 这个command line tool . http://developer.yahoo.com/yslow/commandline/ ,貌似是最近才开源的。反正就是根据Yahoo! 的14 条铁律写出来的一个命令行工具,还可以生成漂亮的web 报表之类的。和 http://www.showslow.com/ 配合就能很好的分析网站的瓶颈了。虽然这个工具对web1.0 网站似乎用途会大一点,但如果能加入 cookie 的话,那也可以适用我们的网站了。据说是支持的。。。空了试用下。

去哪儿分享的《机票实时搜索引擎的优化》。这个是完全偏题的分享!!。。。但内容还ok 。。。根本没有实时搜索引擎相关的什么优化。。。只是说了去哪儿在前端和后端的优化。他们的前端开始的时候使用了 trimpath 这个框架,后来实在有性能问题了,就自己写了一套,我的前端很烂,就不说了。后端的优化说了几个实例。有一个trick , 就是xml 的解析,如果只是需要一个xml 的某些标签的content ,可以不用xml 解析器去把整个xml 解析出来,而是直接用正则把需要的字段抽出来即可,效率相差数量级啊!!还有一个就是memcache 的使用经验,我也曾经犯过这个错,就是分配给memcache 的内存,并不是都可以用于存储的,例如100k data block 会分配一定数目的桶,200k 300k 亦然,当大量小object 占满了100k 的桶子时,memcache 就会根据算法置换一些旧object 出去,也就会出现,分配的512M 内存都没有用完,但就经常miss cache 的情况了。他们说了一点:优化重视细节,但切忌过早过度优化,一开始设计很大,但其实最先出现问题的往往没有考虑过的地方。我也曾经一度陷入这个怪圈,但其实真的没有必要一开始考虑得太多,有时候船到桥头自然直。我现在多数关注的是瓶颈的方面了。