关于SMP Erlang的一些事实
ICFP2008 召开在即，好东西纷纷出笼。下面这一篇是 Erlang/OTP Team 的 Kenneth 为 ICFP2008 准备的 SMP Erlang 相关 Topic 的主要内容。透过这样一篇文档，我们能够了解到 SMP Erlang 的一些内情、策略以及展望，其中对于 SMP Erlang 的不足以及潜在的性能陷阱，也提供了相当富有价值的绕路指引。
Here are some short facts about how the Erlang SMP implementation works and how it relates to performance and scalability.
There will be a more detailed description of how multi-core works and on the future plans available in a couple of weeks. I plan to include some of this in my presentation at the ICFP2008, Erlang Workshop in Victoria BC, September 27
The Erlang VM without SMP support has 1 scheduler which runs in the main process thread. The scheduler picks runnable Erlang processes and IO-jobs from the run-queue and there is no need to lock data structures since
there is only one thread accessing them.The Erlang VM with SMP support can have 1 to many schedulers which are run in 1 thread each. The schedulers pick runnable Erlang processes and IO-jobs from one common run-queue. In the SMP VM all shared data structures are protected with locks, the run-queue is one example of a data structure protected with locks.
From OTP R12B the SMP version of the VM is automatically started as default if the OS reports more than 1 CPU (or Core) and with the same number of schedulers as CPU’s or Cores.
You can see what was chosen at the first line of printout from the “erl” command. E.g.
Erlang (BEAM) emulator version 5.6.4 [source] [smp:4] [asynch-threads:0] …..
The “[smp:4]” above tells that the SMP VM is run and with 4 schedulers.
The default behaviour can be overridden with the “-smp [enable|disable|auto]” auto is default and to set the number of schedulers, if smp is set to enable or auto “+S Number” where Number is the number of schedulers (1..1024)
Note ! that it is normally nothing to gain from running with more schedulers than the number of CPU’s or Cores.
Note2 ! On some operating systems the number of CPU’s or Cores to be used by a process can be restricted with commands. For example on Linux the command “taskset” can be used for this. The Erlang VM will currently only detect number of available CPU’s or Cores and will not take the mask set by “taskset” into account. Because of this it can happen and has happened that e.g. only 2 Cores are used even if the Erlang VM runs with 4 schedulers. It is the OS that limits this because it take the mask from “taskset” into account.
The schedulers in the Erlang VM are run on one OS-thread each and it is the OS that decides if the threads are
executed on different Cores. Normally the OS will do this just fine and will also keep the thread on the same Core throughout the execution.The Erlang processes will be run by different schedulers because they are picked from a common run-queue by
the first scheduler that becomes available.Performance and scalability
————————————- The SMP VM with only one scheduler is slightly slower than the non SMP VM. The SMP VM need to to use all the locks inside but as long as there are no lock-conflicts the overhead caused by locking is not significant (it is the lock conflicts that takes time). This explains why it in some cases can be more efficient to run several SMP VM’s
with one scheduler each instead on one SMP VM with several schedulers. Of course the running of several VM’s require that the application can run in many parallel tasks which has no or very little communication with each other.- If a program scale well with the SMP VM over many cores depends very much on the characteristics of the program, some programs scale linearly up to 8 and even 16 cores while other programs barely scale at all even on 2 cores. This might sound bad, but in practice many real programs scale well on the number of cores that are common on the market today, see below.
- Real telecoms products supporting a massive number if simultaneously ongoing “calls” represented as one or several Erlang processes per core have shown very good scalability on dual and quad core processors. Note, that these products was written in the normal Erlang style long before the SMP VM and multi core processors where available and they could benefit from the Erlang SMP VM without changes and even without need to recompile the code.
SMP performance is continually improved
——————————————————The SMP implementation is continually improved in order to get better performance and scalability. In each service release R12B-1, 2, 3, 4, 5 , …, R13B etc. you will find new optimizations.
Some known bottlenecks
———————————- The single common run-queue will become a dominant bottleneck when the number of CPU’s or Cores increase.
Will be visible from 4 cores and upwards, but 4 cores will probably still give ok performance for many applications. We are working on a solution with one run-queue per scheduler as the most important improvement right now.- Ets tables involves locking. Before R12B-4 there was 2 locks involved in every access to an ets-table, but in R12B-4 the locking of the meta-table is optimized to reduce the conflicts significantly (as mentioned earlier it is the conflicts that are expensive). If many Erlang processes access the same table there will be a lot of lock conflicts causing bad performance especially if these processes spend a majority of their work accessing ets-tables. The locking is on table-level not on record level. Note! that this will have impact on Mnesia as well since Mnesia is a
heavy user of ets-tables.…
Our strategy with SMP
—————————–Already from the beginning when we started implementation of the SMP VM we decided on the strategy: “First make it work, then measure, then optimize”. We are still following this strategy consistently since the first stable working SMP VM that we released in May 2006 (R11B).
There are more known things to improve and we address them one by one taking the one we think gives most performance per implementation effort first and so on.
We are putting most focus on getting consistent better scaling on many cores (more than 4).
Best in class
—————–Even if there are a number of known bottlenecks the SMP system already has good overall performance and scalability and I believe we are best in class when it comes to letting the programmer utilize multi-core machines
in an easy productive way.by.Kenneth Erlang/OTP team, Ericsson
呼唤达人同学出来贡献此文的翻译版本。
update: 出去玩了几天回来，不得不惊呼“Erlang社区的达人真的很多啊！”。竟然有两份中文译版(都翻得不错哦，下下来研究下吧)：
luoyi同学的：http://www.luoyilinux.cn/erlang_smp_zh.pdf
ShiningRay同学的：http://shiningray.cn/some-facts-about-erlang-and-smp.html
package or not? it’s a problem
Erlang 的 maillist 这几天有这么一个帖子：
Time to update programming rules?
7.7 Module names
Erlang has a flat module structure (i.e. there are not modules within modules). Often, however, we might like to simulate the effect of a hierarchical module structure. This can be done with sets of related modules having the same module prefix.
If, for example, an ISDN handler is implemented using five different and related modules. These module should be given names such as:
isdn_init
isdn_partb
isdn_…We have packages! http://www.erlang.se/publications/packages.html
是的，这的确是一个看上去似乎是故意要让人迷糊的问题。一方面 erlang 允许使用 abc.bcd.cde 这样的 module 名称，另一方面 erlang 的 program rule 文档又建议大家在 module 上使用 flat name ，对于初学者而言，想不晕恐怕都很难。
name space 或者说 package 机制对于有 java 背景的人来说，是再熟悉也没有的了。它的好处就是“命名的自由”，“从前”的命名是一件很让人很苦恼事，又要担心“冲突”，又想足够“简洁”，常常让人挠破头皮而不得要领。但在 java 的世界里，这件事就变得异常简单——只要建了一个自己的 com.company.application 的 package，然后你就想怎么命名就怎么命名。想叫 String 也没有关系，大致不会冲突(只能是大致如此，仍有特殊情况)。而且，有了 eclipse 强大的 refactor 功能，你甚至还有了“随时改主意的自由”，又想出了更加牛叉的名字？直接改就是了。一个命令，全部自动搞定。……诸多好处不一而足，而所有这些荣耀，尽皆归于伟大的 name space 。
但从我个人的经验而言， erlang 的 package 虽说已经有了(雏形)，但仍算不上成熟。回帖中的一个举例相当切中要害。
We can, and should, do MUCH MUCH better.
For example, if a module is going to be referred to elsewhere as a.b.c, and if we compile a module M by invoking “erlc M.erl”, then erlc a.b.c.erl should work. (It doesn’t.) Certainly if a module announces itself as “-module(a.b.c)” then compiling it should not produce a simple c.beam. (It does.)
就目前的状况而言，erlang 的 package 仍然只是“允许在 module name 中使用句点的 hack”而已，远远还谈不上“全面的 package 支持”。从 erlang/otp 自己的 souce code tree 来看，其代码的组织方式也并非“基于 package”，而是“基于 application”。在 package 这个问题上，现在的 best practice (到目前为止)仍然是“建一个 application 目录”然后在其中采用 flat module name 即 app_sys_module 这样的命名方式以避免命名冲突。
package 机制对于语言的应用繁荣非常关键(至少是大有裨益) —— cean 项目的诞生也许正是有感于此 —— 多个应用不再需要为了彼此之间有可能产生命名冲突而心存顾忌。这更利于代码重用，比较容易产生“多个应用彼此引用”的叠加效应(比如 mochiweb+couchdb 能重用 json 模块)，而不是目前的“独立应用＋runtime”模式。希望 erlang team 能够关注和改善这个问题。
Google Chrome 崭新浏览器
从“小道消息”变成“大道消息”的最新例子是 google 的浏览器项目 —— Google Chrome 浏览器看[这里]。
据说这个浏览器是开源地。
据说这个浏览器基于 webkit 。
据说这个浏览器内置一个任务管理器。
据说这个浏览器的JSVM叫做V8。
据说这个浏览器的标签长在头上。
据说这个浏览器的9月2日发布(没错，就是今天)。
还等什么，去[看热闹]不？
FF 的 TraceMonkey 加速 JavaScript
对不住，仍然是 JavaScript 的消息， 并不是我存心要改行播报 JavaScript 新闻，而是这条实在太重磅，不报不合适了都。
刚刚还在[上一篇]的回复中数落 FireFox 不务正业地搞什么“多脚本语言支持”，而不去专心加速 JavaScript 的运行。貌似这句话现在我就得自己吞回去了。因为 John Resig 同学博了一篇关于 FireFox v3.1 之中的 TraceMonkey 技术，加速约7倍！这一消息表明 FireFox 内部在 JavaScript 上的投资仍然保持了足够的“密度”。
TraceMonkey 基于 trace tree 理论。是一种 JIT [Just In Time] 优化技术。简单地说，JIT 就是在“合适的时候”（也就是 Just In Time 的要义）将 JavaScript 编译为 native code 再来执行（Java 很早就已经采用 JIT 来提升性能了）。而 trace tree 则对这些 native code 再做进一步的化，比如：优化函数调用，优化类型检测，优化循环，等等。据称，在多项性能测试之中，开启了这一特性之后，脚本的运行性能有了“惊人的”提升。有图为证：
而，这一特性在 nightly build 的 FireFox v3.1 中已经就绪，只需下载，安装，并在 about:config 中打开选项：
- javascript.options.jit.content = true
即可立即开始体验。
顺便八卦一句：FireFox v3.1 的脚本引擎仍然还是 SpiderMonkey，TaceMonkey 只是 SpiderMonkey 的一个版本代号，它有很多代码都是来自于 Adobe 捐赠的 Tamarin 引擎，看来这只猴子的消化力的确很强。
另外八卦一句：打了鸡血的 SpiderMonkey 已经显著超越了 SquirrelFish 的性能。
ECMAScript “和谐号” — JavaScript 的回归
你们一定注意到了——除了 Erlang 之外，这里还充斥着大量的 JavaScript 文章。是的，我喜欢 JavaScript ，我从不掩饰这点。实际上，我一直都是 “Dead Hard” 的 “Web Fundamentalist”（“死硬”的 “Web 原教旨主义者”），我固执（并孤独）的认为面对 “应用全面 Web 化” 的未来，要写出能适应 “爆炸性增长曲线” 的下一代软件（比如象最近老是崩溃的 twitter，不需要 “爆炸” 的软件不在此讨论的范畴之列，比如，给小企业迅猛的做一个百十来人用的系统赚点零花钱），业界所需的 “NEXT BIG ONE” 语言就是 Erlang ，但毫无疑问，它有很多缺陷，同样不能包打天下（基本上，任何声称自己能够包打天下的东西，都很可疑）。比如说，其中很致命的一条就是——在 Client 端的 Erlang 就像是当年的 Java Applet 一样，表现拙劣(几乎可以说是一无是处)。但是借助 HTTP/Ajax/REST/JSON 这一系列标准，或者干脆就说是 HTTP/HTML/JavaScript 的力量，则刚好可以绕过这些限制，而且还有点符合潮流的意思。这么说吧 —— JavaScript 和 Erlang 应该成为一对搭档。
不过 JavaScript 这个搭档之前出了一些状况。简单来说，就是：
[以下内容，纯属文学演义，如有雷同，纯属命名冲突，各大公司，纯属不对号入座]
build block and design tools
distributerl 是最近 google code 上 open 的一个项目，在它的介绍中这样写道：
Building blocks for Erlang/OTP systems using distributed algorithms.
……
Coming soon: generic versioned objects for convenient use with Merkle trees
Coming a bit later: Generic Gossip Protocol
它提供了：Vector clocks, Consistent Hashing, Merkle Trees 这几种分布式算法的 Erlang 实现。此外它还将会提供 Gossip Protocol。
老实说，对于这种后面标有引用论文的算法，我一向都是相当景仰的(也就是说，基本不懂)。在此强烈召唤达人现身，科普一二。但这几个名词的出现频率有猛增的趋势(比如 scalaris 的 pdf, amazon s3 的宕机说明，等等)，因此仍然引起了我的注意。现在的情形似乎是 —— 要是不懂这些大词，看见别的搞“分布式”的，你都不好意思上去打招呼。反正俺是准备知耻而后勇的上去 wikipedia 啃一下英文的了。
与此同时，在 maillist 中也有人正在讨论 Erlang 的 Design Tool。非常好，因为这个问题我已经找了很久，但并未找到答案，若有高人现身说法解我疑惑，那就再好没有了。
关于 design 的问题，我也顺便 blah 一下(当前版本)感想，：
1. 在 Erlang 设计中 UML 的协作图比较好用，能够帮忙理清思路。好多工具都已经“进化”到不再支持这种不是那么 OO 的非主流图型了，如果找不到合适的工具，试试相当老旧的 borland together architect 吧。
2. 用 Erlang 写东西，设计上仍然需要精心设计 API ，也仍然需要在“对象”(或曰进程)“生命周期”的设计决策上浪费大量“生物 CPU”时钟。在这一点上 Erlang 也好 Java 也罢，彼此之间其实并没有太多差别。当然 otp 的 application 或者 gen_xxx 实际上已经在扮演“生命周期管理者”的角色。但，毫无疑问，它的“接口”设计并不怎么“性感”，望之常常让人有“#$@!%*”之感。我在想，是不是也该有个像 Spring for Erlang 这样的东西，把所有“对象”的“生命周期”给管起来呢？
building block for distribute 的通用项目，以及 design tools 的讨论，表明开发者们正在越来越认真的对待 Erlang 语言，这或许也表明大家正从“学习”阶段向“扩大再应用”的阶段转换。
Scalaris 以及内建的 json 支持
最近比较活跃的 Erlang 社区事件是 Scalaris 的代码公布以及 火热的 json BIF 讨论。
Scalaris 就是我们在上一篇中提到的 Alexander Reinefeld 在 Erlang eXchange 2008 上展示的神秘的 Yet An Other Key-Value DB 项目。目前它的源码已经“全文公开”的 host 在 google code 上了，在 [这里] 还有一份 pdf 的 Slide 可以看，比起其他的两个项目，其特色是：
-
All In Memory 数据存储在 gbtree 中 —— 目前还没有提供存储到磁盘的特性。
实现了N多传说中的算法。比如，用来在 P2P 的 DHT 网络中寻址的 Chord 算法 和用来进行数据备份的 Paxos 算法。
据说代码写得相当清晰，极具学习价值。(默念10遍： OpenSource 就是好，就是好，就是好来，就是好)。
另外一件事就是 Joe 老爷爷最近提出了一个 EEP (Erlang Enhancement Process —— Erlang 的特性增强过程，类似于 Java 的 JCP) 要增加一个 Json <--> Term 的 BIF (内建函数)。确实也该如此，现如今 Json 大有称霸江湖的意思，Erlang 的世界里也已经有了 N 多个版本的 Json <--> Term 库，我至少已经领教过 4 个不同的版本了，每个库的 spec 都“略有不同”，颇有些“各自为战，谁都不爽”的意思。推出一个受到广泛认可的 BIF 无疑能够让这个世界立马变得清静许多。
说实话 Json <--> Term 乃至在语法之中直接加入 Json 的支持都算不上是什么难事，但相比由 OTP Team 在下一个版本的 Erlang 中静悄悄的加入某个 BIF 的“独裁”方式， EEP 无疑会是一个更社区化的过程。也就是说，它必然会经历 “提案，方案，辩论，投票” (或类似)的民主化过程，很多时候，这会很“乱糟糟”和“低效”。不过，这些代价绝对能值回票价 —— 最终我们会得到一个无论是在效率还是 API 上都更优秀的 Json <--> Term BIF 。除此之外，对于广大的使用者而言，这个[ “辩论”和“争吵”]的过程，也富有营养 —— 我们不仅(将会)知道最终的方案是什么，还能知道这个方案是怎么来的(比如说，它 PK 掉了哪些其他方案，它们存在着什么样的问题)，这一切就发生在眼前。
erl 的 log4*, bt 以及杂七杂八
etorrent 是最近相当活跃(常能在 maillist 见到 ann )的一个项目，它是用 erlang 实现的一个 bittorrent 客户端。记得刚刚接触 erlang 的时候就觉得它貌似很适合用来写 bittorrent 客户端(分布式/TCP/并发)，深入了解一番了之后，又觉得比起 C 来 erlang 并没有太明显的优势(GUI/CPU Heavy/IO/File)，加之后来见到堪称完美的 uTorrent 横空出世(说实话，除了网上银行，唯一想让我回到 windows 平台的东西就是它了)让人不再有动力作“写 torrent 客户端”之想，没想到时隔一年，还真见到了这样的项目，让人感慨。现在的 etorrent 已经是第二个公开发布的版本了，从它的 change log 看到，特性增强很厉害，以“ 20 个 torrent 占用 50－80M 内存”这样的指标来说，已经相当接近实用水平了。或许日后的 etorrent 再配上一个好用的 frontend 能够打造出像 xmms2 那样强大的软件也说不定呢。
log4erl 是一个 log4* 的 erlang 实现。对于广大习惯了 log4* 的 erlang 使用者来说，确是一个福音。不过，从某种程度上讲，这也可以算是某种“重复建设”—— erlang 自身已经内置了相当强大的日志机制。注意，只是强大，我并没有说易用。因为对于广大 log4* 爱好者们而言，只有能使用 grep/awk/perl 这些标准 unix tool chain 来处理的，格式化的，每条一行的(问题是，以我的经验来说，”每条一行”这种限制常常会逼人多费半天劲，或者多写一大堆)才是易用的日志。而 erlang 自身内置的日志机制说实话也毫不逊色，只是用来颇有一些不同(加之文档组织得别出心裁，让人不易找到)，各自属于不同的风格。既被拔到了“风格”层面，也就参杂了情感因素，无法以简单的方式来区分高下(君不见 csdn 上 x vs y 的口水仗层出不穷无休无止?)。本是见仁见智的事，大家看个人的喜好各取所需就是了。
顺便说说 erlang 自身的日志机制，极简的例子看上去象这样：
[{kernel,
[{error_logger,
{file, "debug.log" }}]}].
这好比是 log 的配置文件，然后，这样用：
1> error_logger:error_report([{tag1,data1},a_term,{tag2,data}]).
ok
2> error_logger:error_report("Serious error in my module").
ok
3> q().
ok
这样，在 debug.log 里面就有了：
=ERROR REPORT==== 17-Jul-2008::11:32:11 ===
tag1: data1
a_term
tag2: data
=ERROR REPORT==== 17-Jul-2008::11:32:31 ===
Serious error in my module
差不多就是这样了，更多配置，相关工具，以及更 “The Erlang Way” 的用法，可以参看文档 SASL 的部分。
btw，升级 wp 时从 incoming link 里发现一个 “默默无闻的领悟Erlang传说” 的中文 blog ToQuick (图快?)，主人 cheng 同学治“程”(程序)态度严谨，细密，文章写得勤也写的好，值得推荐。下面对于 log4erl 的代码观感就转自图快：
log4erl代码非常精简，保持了erlang代码的风格，log4erl包括1个supervisor和2个gen_server和1个gen_event。
log4erl.erl为gen_server和application behaviour的callback，其作为主要的module，
log4erl_sup.erl为supervisor,启动log4erl,初始时将通过log4erl_sup:add_file_logger启动default_logger 日志记录器。
log4erl_sup:add_file_logger/1会动态添加file_logger_guard和file_logger两个child process。
have fun.
经由 Erlang 开源项目之间的合作“铸就”更好的 key-value 存储系统？
自从 Amazon 的 Dynamo 横空出世，开源的 Erlang 的 Key-Value 存储机制(毕竟有一些区别，因此我并不愿意把这个东西称作数据库)似乎已经成为了一个炙手可热的研究领域。先是有 CouchDB (本站多次介绍，已经被 apache 接纳的开源项目)，现在又有了 Kai 。如果算上 Alexander Reinefeld 在 erlang exchange 2008 上展示的项目，很短的时间之内，这一领域已经产生了三个 open source 项目了，可谓进展神速。
说起来，这个新出的 Kai 乃与是我们“一衣带水”的日本同行们的作品。加之此前听说的 Orto，以及零星听说的具有超强并发能力的 tokyocabinet，等。老实说，对于他们在 opensource 领域所表现出来的整体活力，确实有些惊讶。可惜不懂日文，未能对此作进一步的了解。(召唤日语达人整理一下)
话说这几个项目共同关注的是一个相同的问题，然而各自的侧重又略有不同。比如说，Kai 项目实现的乃是(又是) memcache 的访问接口和协议，主要侧重在利用 Erlang 来提升系统在“分布和容错”方面的特性。而 couchDB 则首先关注于实现 key-value 的数据存储本身，在此基础上建立完全不同于 RDBMS 的查询机制，并以优雅的 RESTful 访问接口而著称(Alexander 的项目资料不多，尚不明朗)。应该说是各有特色，而且具有很好的互补性，实在让人很难在这两者之间进行取舍。所以当 couchDB 团队的 Jan Lehnardt 向 Kai 团队的 Takeru Inoue 提出 Collaborate 的建议时，对于广大使用者而言，确实是最为“喜闻乐见”的情形。
或许我们很快就能见到 CouchDB Powered Kai 又或者是 Kai Powered CouchDB，两个项目的特性得到融合，也许，两者之间会形成一种如同 innoDB 之于 mysql 那样的合作关系，谁知道呢？未来充满可能，值得我们期待。开源的 Erlang 就是这么精彩。
上干货 slides on Erlang-Exchange-2008
Erlang-Exchange-2008(别点了，超流量被关啦)刚刚结束，对于我们这些无法亲临现场的“干粉”(干粉＝＝只能干瞪眼的粉丝)而言，等的就是会议结束，各路 slide 纷纷出炉的这一刻。这个场景多少让我想起小时候，看着别人放完炮，一大堆小屁孩就一拥而上，吸溜着鼻涕猛捡那些还没炸完的零碎小鞭炮的岁月。所不同的是，数字时代，每个人都可以捡到“第一手”的干货，不会为了分赃不均而打上一架。不过，任何一个时代，找到干货或者捡到鞭炮的快乐都是相同的，简单而纯粹。下面就是快乐的“干货大放送”(远未集齐，所缺部分希望各位能继续跟帖完善)。
由 Jamaal 同学补充：
在 video.google.com 上搜索 Erlang eXchange 能找到一堆演示视频，虽然没有 PPT/PDF 会略有遗憾，但胜在真人出演，也相当不错。懒得搜索的同学可以点[这里]。
Armstrong on Software: Erlang & SMP,
Joe Armstrong
Introducing Erlang to Motorola: The Journey to Success,
Nicholas Gunder & Torben Hoffman
Erlang- D-Trace,
Garry Bulmer
Erlang & Robotics: The ROSEN Framework at the Eurobot 2008 Competion,
Corrado Santoro
Erlang/OTP Vs Google App Engine, The CEO View,
Gordon Guthrie
Building Web Applications in Erlang,
Xingdong Bian & Michal Slaski
Erlang in Financial Applications,
Dr. Erik Stenman
Erlang and Ajax Web Applications,
Roberto Saccon
Quick Check for Erlang,
John Hughes
Introduction using Faxien & Sinan: Erlang Project Build & Packaging Systems,
Eric Merrit & Martin Logan
Roktalk, Erlang Powered Mobile Conferencing,
Jay Fenton
Wrangerl, The Erlang Refactoring Tool,
Simon Thompson
Enterprise Integration,
Steve Vinoski
Erlang & Tail-F,
Klacke Wikström
Presenting RabbitMQ: An Erlang Based Implementation of AMQP,
Matthias Radestock
EUnit – Lightweight Unit Testing for Erlang,
Richard Carlsson,
ejabberd for web 2.0 development,
Mickael Remond
Load Testing of Web Applications,
Karthik Ramachandra,
Using Jinterface to Bridge Erlang and Java,
Dennis Byrne
Quick Check Tutorial: Using QuickCheck to Test Erlang Programs,
John Hughes & Thomas Arts,
Using Faxien and Sinan, A Hands-on Approach,
Martin Logan & Eric Merrit
Couch DB at 10,000 feet,
Jan Lehnardt
Building a transactional distributed data store with Erlang,
Alexander Reinefeld
Tsung Tutorial,
Mickael Remond,
Erlang Enterprise Integration Panel Discussion,
Garry Bulmer
Recent Comments