Erlang-China

CN-Erlounge IV 圆满结束，各路英豪流出宝藏一大堆。经四处放狗，收刮如下：

0. 各位演讲者帅锅精心准备的演讲 slide

2. 由方块帅锅和莫帅锅 “以某种说不清楚的方式合作” 的 现场剧照
update: 对了，还有 zq 同学的 腐败前哨战实录

3. cn-erlounge-iv 现场抢到了 wifi 的幸运星们联袂演出的华丽 推推乐(请自备工具，以翻墙行动纪念柏林20年前那堵同样“伟大”的墙)

4. ZoomQueit 帅锅整理的 现场原声

5. 同样是由 ZoomQueit 从会场第一线发回的 “现场文字报导”(内容太长，放到后面了，点击 more 展开阅读)

6. yufeng 帅锅言简意赅的总结

7. litaocheng 帅锅同样言简意赅的总结

8. 一位我还没有和真人对上号的帅锅的围观观后感
update: 围观观后感下

这就是 ZoomQueit 帅锅的 “有玄机的文字格式” 的笔记( zq 同学的笔记能力确实可怕)。

091107::

~08:55 到达金溪山庄（关键词：西湖边上 杨公堤岸）

~09:30 大家在沉默的等待开始,和会场的WIFI 进行斗争,終于明白是网页登录,不要关闭中国电信的认证网页,才可以继续上网

~09:33 成立涛 - Erlang开发实践
    N多内容，包含了所有 erl 开发过程中的所有关键实践体验..
~09:45 讲演的幻灯在:
    http://ecug.googlecode.com/svn/trunk/cn-erlounge/iv/litao.cheng/
    当然提及OTP, gen_server 在实践中占到80% 的代码覆盖率，而且其它常用模式也都可用 gen_server 模拟出来！
~09:50 gen_server 是个稳固的 S/C 框架,我们可以放心的在其上进行开发;
    - erl 进程是种抽象概念,是应用的最小单位
    - 不要在gen_server 中进行复杂的处理,以免引发阻塞
    - 这时使用 gen_fsm 这是专门进行处理可能有阻塞的进程处理框架
    - 而且可以使用内置的相互监督模型进行进程脆崩后的自动处理
~09:55 昨日的讲师小聚照片:http://www.flickr.com/photos/zoomq/sets/72157622746793958/
    - appmon 内置的应用进程关系观察工具
    - 相当于JAVA的类树图自动分析,只是这里是对真实的网络进程间关系探测!
~10:01 Emakefile 内置的编译工具,比手工逐一make 可以获得一致性的自动统一编译;
    - 遗憾的是:只能编译.erl 的,无法依赖支持
    - 所以,习惯的使用 GNU make,通过makeconf 进一步加强日常的erl 生产编译行为...
    - 而且可移植!...
~10:05 注释约定! 模块用 %%% 前缀,函式用 %% 前缀...
    - 遗憾的是:edoc 对中文支持不好
    - 嗯嗯嗯,建议使用 Doxygen 之类第3方专业文档化编程工具
~10:13 erl 开发中的逻辑问题解决...
    - 编译过,但是运行不过时的调试技巧! -> plt 的进一步自动分析,来定位可能的编辑问题
    - 使用定制的 dialyzer 测试脚本,定位常见问题...
    - 进一步的,充分使用 EUnit 是个好思路...

~10:50 锋爷:Erlang应用优化指南
    - 网游公司,用erl 开发平台!
    - 对于性能的苛求导致发现短连接响应领域 erl 绝对领先！
    - Taskset -c 1 erl +K true +h 99999 +P 99999 -s ehttpd
    - 严格理解了应用需求后，放弃了垃圾收集等等内置行为后，性能增加 110%
~10:57 erl应该来作什么？
    - I/O密集型/先进的SMP多核支持的 *网络服务器*!!!(或是说专用的操作系统)
    - 为了证明这一感觉，进行了真实的OS 对比
    - 各种组件完全可以和一个OS 的各个部件对应起来！~ etop?!?!?
~11:05 R12B~R13B 最大的变化在进程调度方面，增长了上万行代码！
    - 智能的进行了逻辑CPU 间的协同调度..
    - erl进程是使用操作系统的真实线程
    - 10000/s 的请求,引发的OS消息可以达到 600000/s 内核消息...
    - 调度的单位是 Port 引发的一组I/O事件 ~ erl的调度是由进程和Port 组成的...
~11:11 OS方面的选择优化:
    - 32位性能比64位好(64位没有内存限制,但是性能低20~30%)
    - RHEL 致力于高性能的挖掘>..
    - 配置系统的swapness ,内存的OS预留等默认配置要向已知业务倾斜!
    - 绝大多数erl 死亡都是内存耗光...
~11:15 Hipe 虽然社区认为不稳定,但是实际应用时性能增强非常多!建议使用...
    - 可以省略很多系统特性
    - 未公开的特性: 调度器绑定! ~ 高级特性,可以预先配置CPU 行为..
~12:00 业务方面的优化:
    - 小消息大计算!
    - IO和计算的时间开销比,就是应用的性能收益比!
    - 对CPU和内存及早进行明显的分配!
        - 将业务和实际CPU 对应上,以免引发切换时间消耗...
    - 进程和物理世界的对象尽量 1:1 (erl 的对象控制级别是百万级别的!)
    - 多用ets ~ 大数据量推荐
    - tuple/list/array 只能应作小数据量
    - 尽量 *无锁结构*
~11:40 性能测量的关注:
    + erl/Erts/OS 的热点
        - systemtap ~ 非入侵式旁观
        - Erlang 工具集,非常丰富,非常关注内存的分配...
            - 十多种调度模式
            - 200多种内存锁 lockcounter 就可以观察到问题集中点
            - dbg ~ "ETrace";-)
            ... snmp 综合运行期情况
    + 延迟变化
    + 响应时间的抖动
~11:49 总结优化最佳体验
    - 多用:
        + list comprehension
        + iolist /gather write
        + Binart > 256时，才引用计数(不用复制的！)
        + Hipe_bif 也可以考虑
        - 不要用昂贵的BIF:
            - now()
            - io_lib:format
~11:59 CPU亲缘性利用!
    - Taskset ~ 如果业务明确后,令CPU 对于业务运行从来没有竞争锁,性能将提高 50%以上!
    - 启动OS的内置特性
        + Futex
        + VDSO
        + TCP/IP 协议桟...
            - 大文件句柄(只应微调,根据业务的) 有两面性.. port 等数据结构会自动调整,引发意外操作..
    - 基于测试的持续调优!
~12:05 可诊断的系统
    - 有内部信息暴露的,参数可动态调节的!
    - 测试自动的,有高压力环境的
    - 尽可能的发挥 erts 的优势::
        + 用Ports 整合不同语言系统
        + 用 driver 改写关键性能苛求部分
        + 使用标准协议方便erl 自然处理(Asn.1),使用内置的高级特性...
    - 锁是实际存在的...
        + 尽量减少这方面的代码...
~12:17 Q&A:
    - Q:ets 的使用策略?
    - A:策略!业务决定,在理解erl运行本质后,就容易判决了...

    - Q:百万级应用中,总是有单点node 怎么搞?
    - A:OTP 本身就一直存在这种问题!
        + 尝试使用多个进程来解决
        + 建议在另外一个VM 中进行处理...进行批量的消息移交(共享内存...),而且可以不用erl 的消息处理
    - xiu+A:如果请求间关联不大时,可以使用进程池;
        + 如果有关联时(同资源操作时),晚上有说
    - Q:小消息原则,怎么把握?
    - A:是指消息传递开销小! <5ms
        - 消息传递时间和计算时间比例 > 1:10 才有意义
    - Q:DB方面的操作有不?
    - A:有很多:
        + ets 内存DB;
        + Monisa 内置K/V DB
        + 外部关系数据库的支持不在Erl 哲学中...
~12:30 热烈的进行提问,锋爷的实战体验分享,引爆了好奇心...
    - Q: 加密怎好?
    - A: driver 沟通外部NB模块!
    - Q: 小消息原则应用策略?
    - A: cfg 要特别关注...(原先的 get 方式消耗非常不合算)
        + 先 ets 读入 cfg ,并代理进行维护
        + 其它进程来读ets
    - ~ 分享自个儿的经验:
        + 关系DB 的访问,策略
            - MySQL 的erl 驱动可以用
            - 先用erl 的DB
            - 尽量用 存储过程来计算
        + Asn.1 的标准比 SOAP 要靠谱!得多用!
            - 门槛是 概念和一般的不同
            - 电信工业标准,资料也少...

~14:00 xiu shiwei引言,预告明日的沙龙...

~14:09 老范 开讲EB:
    - 先用实况录像来开始,讲解EB 的实际情景
    - 有机会使用Erl 的情景非常稀少,所以,通过一个简单的程序智力游戏实例来学习,有效,而且可行
~14:25 EB架构的演化:
    - 无名 ets 表,发布战场时况
    - 各种游戏运营过程中的情景
    - 同时行动时的内置顺序聲明
    - 战队算法>..

~15:27 Stewart Mackenzie - An Erlang Implementation of Restms
    - 来自HK 的年轻程序员; 用白人的特色表情,夸张的开始自个儿的 erl 体验分享
    - 也是从Python/Django 过来的,最后选择了 erl 挑战自个儿,对 消息的处置方式...
    - erl 是有近20年的历史了, OTP 却没有被所有人及时的认可...
    - 消息的现实需求和技术解决历史...
~15:40 RestMS 开始忽悠:
    - Twitter 曰: RestMS=AMQP+AtomPub
    - 工作场景基本是对订阅的各种消息进行集约化的处理
    - 并基于路由算法快速使用各种规则进行聚合!
    - 当然的基于HTTP 协议的
~15:50 RestMS.org
    - fireflymq 是 RestMQ 的erl 实现
    - Riak 当然的也支持 MapReduce 模式的计算...
    - Links 式的发布和消息組織形式支持的!
~16:05 创建自个儿的web应用时的思索:
    - RabbitMQ 是 AMQP 的实现
    - RestMQ 是新标准
    - Riak 是RestMQ 的可用实现之一
    - fireflymq 是...

091108::

~09:30 悠然开始...
    - 焜工坊 ! 完全自个儿摸索出来的山寨型"分布式"架构的经验!
~09:45 CMS 在VPS环境中的分布式:
    - 利用老旧的本地机器,形成本地的静态页面工厂,然后自动上传到主机发布
    - 在主机上就地生成网页的话,有峰值现象,无法承受
    - 但是,下面有规模运营体验的同学,就反射式的给出了N多方案...
~09:55 Blender3D渲染工厂
    - 分布式分帧渲染...
    - hypershot 分布式处理; Blender-obj-py-erl-bip-分配给多台hypershot进行渲染
    - 选择erl 另外的原因是：可以最大限度的激发CPU 的所有能力
~10:03 网游原型中的探索:
    - "不开发，只组合"~这一策略来推行
    - 虽然可以找到各种可用的组件，但是总有一些缺憾
    - 使用了各种语言和工具，虽然很乱，但是很有效率！
~10:13 如何用erl简化编程?
    - 现实应用场景,对所有连接进行网关认证...
    - 进入具体方案后,大家直接利用昨天分享的思路进行了分析,非常犀利
    - 进程时间成本已经在本次大会中成立!
~10:17 3D 设计世界的非主流工具体验:
    - Modo 在Nexus 中的强大虚拟系统，可以快速生成各种指定系统中可用的东西？
    小结:
    - 分布式处理的对象:数据或是功能
    - 注意: 细颗粒的裁决；日志记录...

~10:33 MMO(链接管理服务器)侯明园 御风行数码科技有限公司
    - 需求的要求和原有的基本相同，但是要求了高可用性
    - 是要求整合入现有集群?!:
        + DB 使用原生 mysql-erl 驱动
        + 协议要标准！否则一定会反复...但是，已经通过原创的协议解析代码生成器囧解决
~10:44 压力测试测控
    - 之前C++/Py 非常痛苦...
    - 现在,可视化的分布式测试配置/变更/启动/收集
    - GUI 也是用 erl 开发的!(一周就完善)
    - erl 可以理解 wxPy 的wxFormBuild 生成的布局描述文件! xrc
    - 山寨的 loadrunner ...
~11:20 Q&A
    - 进程是消息,要在两处消耗,发现的秘密是  256 时,erl 不进行复制....
    + erl在游戏中的展望:
    - 热部署非常非常必要和贴心!
    - AI 中的协程,erl 大有可为...
    - 运营接口
    - 整合工具 ~ 转接各种运营商的接口标准...

~11:50 午饭
    - 这次按时送到,Pisa ....

~12:50 周爱民 - 谈谈erlang网络环境下的几种数据流转形式
    - 从10试不第的晩唐诗人开始...上马还是下马,进门还是出门?
    - 时间可以证明一切!
    - 踱步而侃...
    - 算法＋数据结构 = 程序
    - 所以，程序不是系统也不是软件！
    - PME 中，P属性和M 方法才在软件中，Events ~ 事件是外星来客...
    - 程序是不考虑时序的系统的静态特定数据结构的抽象...
~13:13 计算机语言范型分类理解...
    - 纯理论的解析了各种语言的目标领域...
    - 在语言层面通过某种组合进行了对时序的理解和处理，但是在OS 呢？
    - erl 领域中的讨论核心是: 网络环境中的数据流转..
    结构化 = 使之成为结构...
        - 1972 年"结构程序设计"牛书 中的内容回顾
            - 数据结构,逻辑结构,...
            - 层次化结构,就是 OOP
~13:21 数据和时间的关系
    - 在途与历史...
    - 由于在途数据有严格的顺序关系,所以一般只能进行事务聚包
    - 数据流动 == 时间流动
    - 即时性系统中好象不重要的:
        - 完整性: 正确性/有效性/一致性
    - AMQP 是有序的吗?
        - 当然不是!
        - 所以,对于有关联的消息队列,应该进行聚包!
        - 后续的:聚合的包,逐一解决时,也通过 MQ 逻辑的话...
        - Sent-ReceiveProxy-Receive
~13:57 即时且有序数据情景的分析
    - 既往和将来
    嗯嗯嗯,纯理性思维不是谁都可以享受的...
    - 映射到系统层面的数据时间角度理解和对策...
    - 简单的系统(聊天室)有可能必须考虑多种数据时序类型的对策..
    对策之一:
        - 顺序消息在 App 处聚包
        - 通过MQ
        - 处理机,解开处理其中之一,然后剩余的打包,继续丢回MQ(头部)
        - 继续...
~14:04 超时 30分钟,到达最后的 Alibaba 实际项目
    - XEngine 的原因...需要中国的 GAE/EC2
    - 几乎每40秒中就说一声,"后面就说" Apsara ~ 飞天系统
    - Alibaba 将独立开发一个独立的内部 Google API 集群,提供B2B 应用服务商的所有关键服务..
~14:44 瓶颈在于 AJAV 原生VM无法加载多应用!
    - 后羿 系统已经完成论证,3年内覆盖 2.5万台主机运营
        - XEngine 当前 就2人,其中一名实习生
        - 后羿 有10人左右
    - erlang 入门和使用非常快
    - 明年, taobao 非关键业务将使用这一体系...
    - 先降低 taobao 支付宝 的硬件成本

t2t格式很整洁很强大，不是嘛？

my 2 cents:
1. 没去成，很后悔。
2. 帅锅太多，聚会要低调。

misc