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

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

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

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

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

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 的情况了。他们说了一点：优化重视细节，但切忌过早过度优化，一开始设计很大，但其实最先出现问题的往往没有考虑过的地方。我也曾经一度陷入这个怪圈，但其实真的没有必要一开始考虑得太多，有时候船到桥头自然直。我现在多数关注的是瓶颈的方面了。