首先,库存在的目的大致可分为:
1、提供便利
2、尽可能解决一些痛点

首先,我们先明确一下Erlang编程语言的一些痛点(伪痛点):
1,单进程问题
Erlang虚拟机属于抢占式调度,抢占式调度有很多好处,但是同样也存在这弊端。虚拟机在默认情况下分配个每个进程的资源都是相同的,但是若一个进程(gen_server/event/fsm)要为其他许多进程提供服务,这个进程就极有可能成为整个Erlang系统的瓶颈所在。http://www.cnblogs.com/--00/p/4277640.html
2,列表解析效率
在Erlang编程语言中,list/string 是非常常见的一种数据类型,list处理的方式几乎都是遍历或者是尾递归,在list规模小的情况下,这种方式几乎不会给大家造成麻烦,但是一旦list的规模很大之后,情况就会变得非常糟糕。如list的“++”操作存在陷阱,erlang:length(List) 存在陷阱,queue:len(Queue)存在陷阱,诸如这种陷阱看起来很细碎,但是如果不好好处理,指不定就容易出现各种让我们摸不着头脑的坑。
> 前不久,我们刚刚在一个系统中,优化了一个lists:keydelete/3 的操作,大幅度提升了整个接口处理的速度。
当然,这些问题和erts的设计思路有很大的关系,如:private heap,变量不变 ... 。
3,refc binary
binary的存在在一定程度上缓解了list处理带来的“低效率”的问题,但是,refc binary(erlang:byte_size(Binary) > 64的binary)的gc又让人比较蛋疼。Erlang process structure -- refc binary
4,OOM
在一定程度上,这也是单进程问题的一个附属品。单进程获得虚拟机资源有限,处理性能不足,导致message mail box 的message不断挤压,继而引发large heap,导致整个Erlang 虚拟机crash。最最典型的就是lager了。
5,Erlang进程CPU消耗度量
一直以来,大家都在社区中试图寻找度量单个Erlang进程CPU的消耗,但是不管是Erlang现在的API函数,还是社区中的方案,都没有提供一种行之有效的方案。为什么?我简单摘抄一段Erlang_IN_Anger中的一段描述吧:
> It is generally difficult to properly analyze the CPU usage of an Erlang node to pin problems to a specific piece of code. With everything concurrent and in a virtual machine, there is no guarantee you will find out if a specific process, driver, your own Erlang code, NIFs you may have installed, or some third-party library is eating up all your processing power.



那么,究竟有哪些库,能帮我们解决(或者是缓解)这些痛点,能给我们带来便利?
1、riak_sysmon
github : basho/riak_sysmon · GitHub
对erlang:system_monitor/0,1,2 的封装,尽快的发现系统中存在的long_gc,large_heap等性能隐患。针对上述痛点中的“refc binary”和“OOM”。
2、recon
github : ferd/recon · GitHub
封装了erlang:process_info/1,2 函数,并提供了TOPN的feature,recon_alloc封装了度量虚拟机内部内存的使用量的查询。
不仅如此,recon提供了一种近似度量Erlang进程CPU消耗的方案,Erlang tool -- recon ,memory leak的检查。针对上述痛点中的“Erlang进程CPU消耗度量”、“refc binary”,并且提供了种种便利。好用到爆的感觉。
3、eper/redbug
github : massemanet/eper · GitHub
刚开始接触Erlang时,社区提供的一种代码调试方案是日志。然,这种方式太不优雅,使用起来非常麻烦。
redbug是对Erlang系统中dbg模块的封装,提供了非常安全有效的代码调试方式。“安全”对生产环境来说,确实太过重要了。
4、pooler/poolboy
github : seth/pooler · GitHub
github : devinus/poolboy · GitHub
池。Erlang单进程效率的问题,非常常见的三种方式,第一种是池,第二种是noblock call,第三种是修改某个进程的资源配置。
在社区中,常见的是第一种方案,而第二种和第三种方案常见于Erlang编程语言编源码中(rpc模块,net_kernel模块)。针对上述痛点中的“单进程问题”。
5、jiffy
github : davisp/jiffy · GitHub
json处理库,而且是nif的,能够尽可能保证效果,并且可以支持return_maps已经encode force_utf8,decode 的return_maps能直接返回map 数据类型,非常之方便。(虽然17的map效率不怎么样,但是18版本做了很大的优化)
6、entop
github : mazenharake/entop · GitHub
有没有觉得Erlang自带的etop有些难用?entop提供了非常不错的可替代方案。
7、erlang-lz4
github : szktty/erlang-lz4 · GitHub
不管是Erlang系统,还是其他系统,所倡导的都是“小消息,大计算”,加之Erlang消息传递是值传递的方式,对于大的message,稍微做一下压缩,获取能取得意想不到的效果。不放试一试,lz4 的算法,请Google 之。

8、sync
github : rustyio/sync · GitHub
on-the-fly recompiling and reloading in Erlang. 大幅度提高工作效率,避免接二连三的重新compile、generate。不过,要注意的是,最好只用在开发环境下。
> 关于热更,多叨叨两句:
> 1,在supervisor下增删 gen_server child 热更会失败,目前无解,除非修改supervisor源代码
> 2,gen_server record 增删字段,这个可用 “使用proplists字段值”或者是“map字段值”
> 3,gen_server init 函数逻辑无法热更,解决办法,重写code_change 代码
> 至于常规的逻辑代码,热更基本上没什么问题
9、erlang_term
github : okeuday/erlang_term · GitHub
存了一个Term到ETS表中,难道不应该知道这个Term到底占用了多大的内存空间吗?要send一个大的message给另一个进程,不度量一点内存占用大小就随心所欲?恐怕不太好。erlang_term可以作为贴心小工具。Erlang ets -- something about cache continue
10、folsom
github : boundary/folsom · GitHub
提供了多种Metrics 模型,根据自己的应用场景,选择不同的模型就行。内部主要使用ets:update_counter/3,4,性能效果很有保证。
11、ej
github : seth/ej · GitHub
Helper module for working with Erlang terms representing JSON
试试就知道有没有意思,好不好玩了。
12、task
github : redink-toys/task · GitHub
遇到过这样一个有意思的场景:主进程是一个普通进程,有10W量级的列表,我想将其过滤之后,将1/2或者是1/4的列表写入到ETS表中,然后进行后续的操作。如果我在主进程中做这一些列操作,这个主进程就会被挂住,因为GC(Erlang的GC不会STW,但很有可能会STP)。考虑到ETS表可以在不同的进程之间共享数据,我就可以在主进程中spawn一个进程,这个这个进程去执行过滤、写入操作,然后这个进程生命周期结束之后,GC是很简单快速的。
task就是一个spawn、receive的简单封装。
13、xref_runner
github : inaka/xref_runner · GitHub
做xref检查:善待Erlang 代码 -- Xref 实践

posted on 2015-08-14 20:23  _00  阅读(1670)  评论(0编辑  收藏  举报