The Erlang Library--Interesting library summary

First, the purpose of the library's existence can be broadly divided into:
1. Provide convenience
2, as far as possible to solve some pain points

First, let's clarify some of the pain points in the Erlang programming language (pseudo-pain points):
1, single process issue
Erlang virtual machine belongs to preemptive scheduling, and preemptive scheduling has many advantages, but it also has the disadvantage. Virtual machines are allocated the same resources by default for each process, but if one process (GEN_SERVER/EVENT/FSM) is to serve many other processes, the process is most likely to be a bottleneck for the entire Erlang system. Http://www.cnblogs.com/--00/p/4277640.html
2, list resolution efficiency
In the Erlang programming language, list/string is a very common type of data, and the list is handled almost in the form of traversal or tail recursion, and in the case of a small list, this approach rarely causes trouble, but once the list size is large, Things are going to get really bad. such as the list of "+ +" operation there is a trap, erlang:length (list) There is a trap, Queue:len (queue) There is a trap, such as the trap looks very fine, but if not properly dealt with, it is easy to have a variety of things let us feel the hole of the mind.
Shortly before >, we had just optimized a LISTS:KEYDELETE/3 operation in a system that greatly increased the speed of the entire interface processing.
Of course, these problems and erts design ideas have a great relationship, such as: Private heap, variable ....
3,REFC binary
The existence of binary eases the "inefficiency" of list processing, but the GC of REFC binary (binary > 64 binary) makes the egg more painful. Erlang process Structure--REFC binary
4,oom
To some extent, this is also an adjunct to the single-process problem. Single-process acquisition of virtual machine resources is limited, processing performance is insufficient, resulting in message mail box message is constantly squeezed, and then raised large heap, resulting in the entire Erlang virtual machine crash. The most typical is the lager.
5,erlang Process CPU consumption metrics
All along, everyone in the community is trying to find a way to measure the CPU consumption of a single erlang process, but neither the current API functions of Erlang nor the scenarios in the community provide an effective solution. Why? Let me briefly extract a description of a 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 vsan, there is no guarantee you'll find out if a specific process, driver , your own Erlang code, NIFs you could have installed, or some third-party the library is eating up all your processing power.



So, what are the libraries that can help us solve (or alleviate) these pain points and bring us convenience?
1, Riak_sysmon
Github:basho/riak_sysmon GitHub
The erlang:system_monitor/0,1,2 package, as soon as possible to find the system in the presence of long_gc,large_heap and other performance hazards. For the above pain points in the "REFC binary" and "OOM".
2, Recon
Github:ferd/recon GitHub
Encapsulates the erlang:process_info/1,2 function and provides a query that TOPN Feature,recon_alloc encapsulates the amount of internal memory used to measure a virtual machine.
Not only that, Recon provides an approximate measure of the Erlang process CPU consumption, Erlang tool-Recon, memory leak check. For the "Erlang Process CPU consumption metric", "REFC binary" in the pain points above, and provides various conveniences. Easy to use to explode the feeling.
3, Eper/redbug
Github:massemanet/eper GitHub
When we first approached Erlang, the community provided a code debugging scenario that was a log. However, this approach is too elegant and cumbersome to use.
Redbug is a package of DBG modules in the Erlang system, providing a very safe and efficient way to debug your code. "Security" is really too important for a production environment.
4, Pooler/poolboy
Github:seth/pooler GitHub
Github:devinus/poolboy GitHub
Pool. Erlang single process efficiency problem, very common three ways, the first is the pool, the second is Noblock call, the third is to modify the resource configuration of a process.
In the community, the first scenario is common, while the second and third scenarios are common in the Erlang programming language source code (RPC module, Net_kernel module). For the "single process Problem" in the above pain points.
5, Jiffy
Github:davisp/jiffy GitHub
JSON processing library, and is NIF, can guarantee the effect as much as possible, and can support return_maps already encode Force_utf8,decode Return_maps can directly return the map data type, very convenient. (Although the 17 map is inefficient, the 18 version has been greatly optimized.)
6, Entop
Github:mazenharake/entop GitHub
Do you think the etop from Erlang is a little hard to use? Entop offers a very good alternative to the program.
7, Erlang-lz4
Github:szktty/erlang-lz4 GitHub
Whether it is the Erlang system, or other systems, is advocated by "small message, big calculation", plus Erlang message delivery is the way of value delivery, for a large message, a little bit of compression, get to achieve unexpected results. Do not put a try, lz4 algorithm, please google.

The Erlang Library--Interesting library summary