[ErloungIV]ZQ 现场流水报道{OT}
Zoom.Quiet
091107::
~08:55 到达金溪山庄（关键词：西湖边上 杨公堤岸）
~09:30 大家在沉默的等待开始,和会场的WIFI 进行斗争,終于明白是网页登录,不要关闭中国电信的认证网页,才可以继续上网
~09:33 成立涛 - Erlang开发实践
N多内容，包含了所有 erl 开发过程中的所有关键实践体验..
--
http://zoomquiet.org 人生苦短? Pythonic!
usage 7-zip to replace WinRAR/WinZip; You can get the truely Freedom 4 software.
Zoom.Quiet
http://ecug.googlecode.com/svn/trunk/cn-erlounge/iv/litao.cheng/
当然提及OTP, gen_server 在实践中占到80% 的代码覆盖率，而且其它常用模式也都可用 gen_server 模拟出来！
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
金山常年招聘Py/C++人才! http://bit.ly/UoTV 简历直投俺就成;-)
Zoom.Quiet
- erl 进程是种抽象概念,是应用的最小单位
- 不要在gen_server 中进行复杂的处理,以免引发阻塞
- 这时使用 gen_fsm 这是专门进行处理可能有阻塞的进程处理框架
- 而且可以使用内置的相互监督模型进行进程脆崩后的自动处理
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
向靠谱,反脑残! Kaopulity,小白退散! [Kaopulity~= Keep all processes usablity!]
Zoom.Quiet
- appmon 内置的应用进程关系观察工具
- 相当于JAVA的类树图自动分析,只是这里是对真实的网络进程间关系探测!
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!
Zoom.Quiet
- 遗憾的是:只能编译.erl 的,无法依赖支持
- 所以,习惯的使用 GNU make,通过makeconf 进一步加强日常的erl 生产编译行为...
- 而且可移植!...
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
流程是对先前蠢行的内在反应! ~ Clay Shirky (Process is an embedded reaction to prior
stupidity)http://bit.l...
Zoom.Quiet
- 遗憾的是:edoc 对中文支持不好
- 嗯嗯嗯,建议使用 Doxygen 之类第3方专业文档化编程工具
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Time is unimportant, only life important!
Zoom.Quiet
- 编译过,但是运行不过时的调试技巧! -> plt 的进一步自动分析,来定位可能的编辑问题
- 使用定制的 dialyzer 测试脚本,定位常见问题...
- 进一步的,充分使用 EUnit 是个好思路...
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
过程改进乃是催生可促生靠谱的人的组织! (ProcessEnhancement keeps evolving organizations
which promoting people b...
Zoom.Quiet
- 网游公司,用erl 开发平台!
- 对于性能的苛求导致发现短连接响应领域 erl 绝对领先！
- Taskset -c 1 erl +K true +h 99999 +P 99999 -s ehttpd
- 严格理解了应用需求后，放弃了垃圾收集等等内置行为后，性能增加 110%
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
KM乃是培育可催生自学习型组织的文化氛围! (KM=Knowledge Management=知识管理)
Zoom.Quiet
- I/O密集型/先进的SMP多核支持的 *网络服务器*!!!(或是说专用的操作系统)
- 为了证明这一感觉，进行了真实的OS 对比
- 各种组件完全可以和一个OS 的各个部件对应起来！~ etop?!?!?
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
工作的层次(依靠谱程度从低到高)=有做-＞做完-＞做对-＞做好-＞帮助他人做好
Zoom.Quiet
- 智能的进行了逻辑CPU 间的协同调度..
- erl进程是使用操作系统的真实线程
- 10000/s 的请求,引发的OS消息可以达到 600000/s 内核消息...
- 调度的单位是 Port 引发的一组I/O事件 ~ erl的调度是由进程和Port 组成的...
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 32位性能比64位好(64位没有内存限制,但是性能低20~30%)
- RHEL 致力于高性能的挖掘>..
- 配置系统的swapness ,内存的OS预留等默认配置要向已知业务倾斜!
- 绝大多数erl 死亡都是内存耗光...
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Free as in Freedom! 哲思社区:http://zeuux.com
Zoom.Quiet
- 可以省略很多系统特性
- 未公开的特性: 调度器绑定! ~ 高级特性,可以预先配置CPU 行为>..
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 小消息大计算!
- IO和计算的时间开销比,就是应用的性能收益比!
- 对CPU和内存及早进行明显的分配!
- 将业务和实际CPU 对应上,以免引发切换时间消耗...
- 进程和物理世界的对象尽量 1:1 (erl 的对象控制级别是百万级别的!)
- 多用ets ~ 大数据量推荐
- tuple/list/array 只能应作小数据量
- 尽量 *无锁结构*
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
KM乃是培育可催生自学习型组织的文化氛围! (KM=Knowledge Management=知识管理)
Zoom.Quiet
+ erl/Erts/OS 的热点
- systemtap ~ 非入侵式旁观
- Erlang 工具集,非常丰富,非常关注内存的分配...
- 十多种调度模式
- 200多种内存锁 lockcounter 就可以观察到问题集中点
- dbg ~ "ETrace";-)
... snmp 综合运行期情况
+ 延迟变化
+ 响应时间的抖动
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 多用:
+ list comprehension
+ iolist /gather write
+ Binart > 256时，才引用计数(不用复制的！)
+ Hipe_bif 也可以考虑
- 不要用昂贵的BIF:
- now()
- io_lib:format
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- Taskset ~ 如果业务明确后,令CPU 对于业务运行从来没有竞争锁,性能将提高 50%以上!
- 启动OS的内置特性
+ Futex
+ VDSO
+ TCP/IP 协议桟...
- 大文件句柄(只应微调,根据业务的) 有两面性.. port 等数据结构会自动调整,引发意外操作..
- 基于测试的持续调优!
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 有内部信息暴露的,参数可动态调节的!
- 测试自动的,有高压力环境的
- 尽可能的发挥 erts 的优势::
+ 用Ports 整合不同语言系统
+ 用 driver 改写关键性能苛求部分
+ 使用标准协议方便erl 自然处理(Asn.1),使用内置的高级特性...
- 锁是实际存在的...
+ 尽量减少这方面的代码...
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 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 哲学中...
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!
Zoom.Quiet
- Q: 加密怎好?
- A: driver 沟通外部NB模块!
- Q: 小消息原则应用策略?
- A: cfg 要特别关注...(原先的 get 方式消耗非常不合算)
+ 先 ets 读入 cfg ,并代理进行维护
+ 其它进程来读ets
- ~ 分享自个儿的经验:
+ 关系DB 的访问,策略
- MySQL 的erl 驱动可以用
- 先用erl 的DB
- 尽量用 存储过程来计算
+ Asn.1 的标准比 SOAP 要靠谱!得多用!
- 门槛是 概念和一般的不同
- 电信工业标准,资料也少...
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
~14:09 老范 开讲EB:
- 先用实况录像来开始,讲解EB 的实际情景
- 有机会使用Erl 的情景非常稀少,所以,通过一个简单的程序智力游戏实例来学习,有效,而且可行
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 无名 ets 表,发布战场时况
- 各种游戏运营过程中的情景
- 同时行动时的内置顺序聲明
- 战队算法>..
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!
Zoom.Quiet
- 来自HK 的年轻程序员; 用白人的特色表情,夸张的开始自个儿的 erl 体验分享
- 也是从Python/Django 过来的,最后选择了 erl 挑战自个儿,对 消息的处置方式...
- erl 是有近20年的历史了, OTP 却没有被所有人及时的认可...
- 消息的现实需求和技术解决历史...
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- Twitter 曰: RestMS=AMQP+AtomPub
- 工作场景基本是对订阅的各种消息进行集约化的处理
- 并基于路由算法快速使用各种规则进行聚合!
- 当然的基于HTTP 协议的
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
> ~15:27 Stewart Mackenzie - An Erlang Implementation of Restms
> - 来自HK 的年轻程序员; 用白人的特色表情,夸张的开始自个儿的 erl 体验分享
> - 也是从Python/Django 过来的,最后选择了 erl 挑战自个儿,对 消息的处置方式...
> - erl 是有近20年的历史了, OTP 却没有被所有人及时的认可...
> - 消息的现实需求和技术解决历史...
>
>
>
> 2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
>> ~14:25 EB架构的演化:
>> - 无名 ets 表,发布战场时况
>> - 各种游戏运营过程中的情景
>> - 同时行动时的内置顺序聲明
>> - 战队算法>..
>>
>> 2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
>>> ~14:00 xiu shiwei引言,预告明日的沙龙...
>>>
>>> ~14:09 老范 开讲EB:
>>> - 先用实况录像来开始,讲解EB 的实际情景
>>> - 有机会使用Erl 的情景非常稀少,所以,通过一个简单的程序智力游戏实例来学习,有效,而且可行
>>>
--
http://zoomquiet.org 人生苦短? Pythonic!
Zoom.Quiet
- fireflymq 是 RestMQ 的erl 实现
- Riak 当然的也支持 MapReduce 模式的计算...
- Links 式的发布和消息組織形式支持的!
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- RabbitMQ 是 AMQP 的实现
- RestMQ 是新标准
- Riak 是RestMQ 的可用实现之一
- fireflymq 是...
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 先澄清 并行和并发计算的不同!
- 神曲的插图... 反云计算的思考!
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
KM乃是培育可催生自学习型组织的文化氛围! (KM=Knowledge Management=知识管理)
Zoom.Quiet
- Erl/OpenMP/Cilk/TBB 粗颗粒并行
- GPGPU/CUDA/OpenCL...精密并行
- Coarse Gained us 級别
- Fine Gained ns 級别
- 进入 Bit世界,离开 Bety 级别!
- "普朗克尺度"
- 这时的编程是量子体验的,几乎所有的原有编程体验都不靠谱的!
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
> 天那从早上9点轰炸到下午5点了。
>
> 能不能不用邮件列表进行实时报道？
> 我订阅了那么多邮件列表，如果每个邮件列表都进行实时报道，我岂不是要疯掉。
>
嗯嗯嗯,到现在就俺这么作过几次,
我们的列表订阅重复的太厉害了,
好的集中到 ECUG 先,,
>> _______________________________________________
>> zeuux-universe mailing list
>> zeuux-u...@zeuux.org
>> http://www.zeuux.org/mailman/listinfo/zeuux-universe
>>
>> ZEUUX Project - Free Software, Free Society!
>> http://www.zeuux.org
>
>
--
http://zoomquiet.org 人生苦短? Pythonic!
Zoom.Quiet
- Thread/Block 的维度,3维的!
- praprapra.... 血淋淋的技术细节,不过,很高兴,中国有公司愿意付钱让T1来研究这种基础技术
- 远程渲染的时间核算,给 CPU 只有10ms 的时间来作,已经不可能了!
- 所以,进入 GPU专用的 CUDA Jepg 世界
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 整整6个步骤,其中只有最先的3步可以并行
- 性能瓶颈在后面的过程
原先 430us ! CUDA 只有 135us!
- 逐一优化!
+ 8x8 的并行图形处理,DU->MCU 嗯嗯嗯,开始奇异的思维体操
+ 算法优化,将计算尽量变成位运算...
? 输出时 Plan 和 Packed的决择: 问题在内存操作效率
- 取决于 Zig-Zag 算法...
-> 使用Plan 输出
进入 70us
+ Fourier Serise/Trandform + Discrete Cosine Transform(DCT)
- 实数域上的一种特殊傅立叶变换
- Jpeg 的压缩值 就是使用数学变换计算放弃人眼不敏感的高频颜色,从而得到图片体积的压缩
- 再进行矩阵运算的优化,分行列分别计算,降价复杂度到 O(N^3) <- O(N^4)
- 得到 153us (28次加,24次乘)
+ 使用数字变换,AAN 算法后,得到 O(nlogn) 复杂度
- 消去 16次浮点乘法
-> 119us
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- RLE 阶段,准备输出了...
- 将线性化的系数序列变成描述码
- 使用haffman 表,进一步将描述码压缩成 Bit 码
- 但是 Bit Packet 有强烈的前效性...
+ 先作前项合,然后/16 取模,就可以知道怎么拼字节...
+ 才可以得出并行计算的切分策略
-> Prefix Sum 前项合消除算法
- 很多种,其中 Nvidia version, 复杂度串行的 O(n); 2*(n-1)加,并行 O(n/p+lgn)
-> 改进为盛大版本 每线程处理c个前向和 [Log c N]的速度收敛...
感觉这一路的东西,真的应该在大学课程中出现哪!
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
KM乃是培育可催生自学习型组织的文化氛围! (KM=Knowledge Management=知识管理)
Zoom.Quiet
- 8x8 解码后,是不定长的,怎么拼回来?
- 稀疏数组的分析: 一般两组Integer 128x2 的输出比较容易处理
- 一样使用前项合,并复用内存空间,使用最后一个数值标识,复制出有效的结果
- 进一步优化,对数据块的索引分析位再进行前项合,以便获得索引数,完成归并
? RLE 中的0值计数算法问题...
- Byte级别的循环转换为 Bit 上的位运算
- Parallel reduce 算法用或运算完成加
- 使用 CLZ 算法来统计每个 thread 的0系数数量
- 使用 POPC 算法来统计每个 thread 的!0系数数量
- 但是最后面对纹理依然没有办法...
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
~20:50 51.com 的同学说C++ 的erl 模式实践
- 平稳的念完了幻灯，但是也引发了讨论，的确C++的人多哪
- xiu shiwiu 也非常有感触，进行了打边鼓...
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 不得了,C++ 们非常高兴也非常怀疑这种急就章的准OS 平台框架是否实用
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- Boost.ASIO 的分析,针对IO组织代码,提高运行效率;但是代码被IO切割,很分散
- 进一步的进程/纤程,在C++ 中理解的Erl 进程调度,,,
- 语法糖还是人靠谱,或是模块库靠谱?
- shiwei.xu 很纠结的当众想公开自个儿思維的顿点,,,
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
KM乃是培育可催生自学习型组织的文化氛围! (KM=Knowledge Management=知识管理)
Zoom.Quiet
== 091108 am ==
09:00 到场
~09:30 悠然开始...
- 焜工坊 ! 完全自个儿摸索出来的山寨型"分布式"架构的经验!
2009/11/7 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 利用老旧的本地机器,形成本地的静态页面工厂,然后自动上传到主机发布
- 在主机上就地生成网页的话,有峰值现象,无法承受
- 但是,下面有规模运营体验的同学,就反射式的给出了N多方案...
2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
> 又一日密集分享....
> == 091108 am ==
> 09:00 到场
> ~09:30 悠然开始...
> - 焜工坊 ! 完全自个儿摸索出来的山寨型"分布式"架构的经验!
>
--
http://zoomquiet.org 人生苦短? Pythonic!
Zoom.Quiet
- 分布式分帧渲染...
- hypershot 分布式处理; Blender->obj->py->erl->bip->分配给多台hypershot进行渲染
- 选择erl 另外的原因是：可以最大限度的激发CPU 的所有能力
2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
> ~09:45 CMS 在VPS环境中的分布式:
> - 利用老旧的本地机器,形成本地的静态页面工厂,然后自动上传到主机发布
> - 在主机上就地生成网页的话,有峰值现象,无法承受
> - 但是,下面有规模运营体验的同学,就反射式的给出了N多方案...
>
> 2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
>> 又一日密集分享....
>> == 091108 am ==
>> 09:00 到场
>> ~09:30 悠然开始...
>> - 焜工坊 ! 完全自个儿摸索出来的山寨型"分布式"架构的经验!
--
http://zoomquiet.org 人生苦短? Pythonic!
Zoom.Quiet
- "不开发，只组合"~这一策略来推行
- 虽然可以找到各种可用的组件，但是总有一些缺憾
- 使用了各种语言和工具，虽然很乱，但是很有效率！
2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
> ~09:55 Blender3D渲染工厂
> - 分布式分帧渲染...
> - hypershot 分布式处理; Blender->obj->py->erl->bip->分配给多台hypershot进行渲染
> - 选择erl 另外的原因是：可以最大限度的激发CPU 的所有能力
>
> 2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
>> ~09:45 CMS 在VPS环境中的分布式:
>> - 利用老旧的本地机器,形成本地的静态页面工厂,然后自动上传到主机发布
>> - 在主机上就地生成网页的话,有峰值现象,无法承受
>> - 但是,下面有规模运营体验的同学,就反射式的给出了N多方案...
>>
>> 2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
>>> 又一日密集分享....
>>> == 091108 am ==
>>> 09:00 到场
>>> ~09:30 悠然开始...
>>> - 焜工坊 ! 完全自个儿摸索出来的山寨型"分布式"架构的经验!
--
http://zoomquiet.org 人生苦短? Pythonic!
Zoom.Quiet
- Modo 在Nexus 中的强大虚拟系统，可以快速生成各种指定系统中可用的东西？
小结:
- 分布式处理的对象:数据或是功能
- 注意: 细颗粒的裁决；日志记录...
2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 需求的要求和原有的基本相同，但是要求了高可用性
- 是要求整合入现有集群?!:
+ DB 使用原生 mysql-erl 驱动
+ 协议要标准！否则一定会反复...但是，已经通过原创的协议解析代码生成器囧解决
2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 之前C++/Py 非常痛苦...
- 现在,可视化的分布式测试配置/变更/启动/收集
- GUI 也是用 erl 开发的!(一周就完善)
- erl 可以理解 wxPy 的wxFormBuild 生成的布局描述文件! xrc
- 山寨的 loadrunner ...
2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 现实应用场景,对所有连接进行网关认证...
- 进入具体方案后,大家直接利用昨天分享的思路进行了分析,非常犀利
- 进程时间成本已经在本次大会中成立!
2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 进程是消息,要在两处消耗,发现的秘密是 > 256 时,erl 不进行复制....
+ erl在游戏中的展望:
- 热部署非常非常必要和贴心!
- AI 中的协程,erl 大有可为...
- 运营接口
- 整合工具 ~ 转接各种运营商的接口标准...
2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
Zoom.Quiet
- 从10试不第的晩唐诗人开始...上马还是下马,进门还是出门?
- 时间可以证明一切!
- 踱步而侃...
- 算法＋数据结构 = 程序
- 所以，程序不是系统也不是软件！
- PME 中，P属性和M 方法才在软件中，Events ~ 事件是外星来客...
- 程序是不考虑时序的系统的静态特定数据结构的抽象...
2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!
Zoom.Quiet
- 纯理论的解析了各种语言的目标领域...
- 在语言层面通过某种组合进行了对时序的理解和处理，但是在OS 呢？
- erl 领域中的讨论核心是: 网络环境中的数据流转..
结构化 = 使之成为结构...
- 1972 年"结构程序设计"牛书 中的内容回顾
- 数据结构,逻辑结构,...
- 层次化结构,就是 OOP
2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 在途与历史...
- 由于在途数据有严格的顺序关系,所以一般只能进行事务聚包
- 数据流动 == 时间流动
- 即时性系统中好象不重要的:
- 完整性: 正确性/有效性/一致性
- AMQP 是有序的吗?
- 当然不是!
- 所以,对于有关联的消息队列,应该进行聚包!
- 后续的:聚合的包,逐一解决时,也通过 MQ 逻辑的话...
-> Sent->ReceiveProxy->Receive
2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- 既往和将来
嗯嗯嗯,纯理性思维不是谁都可以享受的...
- 映射到系统层面的数据时间角度理解和对策...
- 简单的系统(聊天室)有可能必须考虑多种数据时序类型的对策..
对策之一:
-> 顺序消息在 App 处聚包
-> 通过MQ
-> 处理机,解开处理其中之一,然后剩余的打包,继续丢回MQ(头部)
-> 继续...
2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
- XEngine 的原因...需要中国的 GAE/EC2
- 几乎每40秒中就说一声,"后面就说" Apsara ~ 飞天系统
- Alibaba 将独立开发一个独立的内部 Google API 集群,提供B2B 应用服务商的所有关键服务..
2009/11/8 Zoom.Quiet <zoom....@gmail.com>:
Zoom.Quiet
http://www.woodpecker.org.cn/share/media/2009-erloung-iv/
~14:44 瓶颈在于 AJAV 原生VM无法加载多应用!
- 后羿 系统已经完成论证,3年内覆盖 2.5万台主机运营
- XEngine 当前 就2人,其中一名实习生
- 后羿 有10人左右
- erlang 入门和使用非常快
- 明年, taobao 非关键业务将使用这一体系...
- 先降低 taobao 支付宝 的硬件成本
-
2009/11/8 Zoom.Quiet <zoom....@gmail.com>: