怎样限制ERLANG 程序进程数

[huangjiawei]

看 erlang 程序设计的时候，多核编程。里面说进程不是越多越好。有时候要限制进程。但是没有给出限制进程的例子。请教各位。如何限制进程。限制进程以后。如何发挥erlang的性能？

[老范]

这个问题要看具体应用场景。 进程当然不是越多越好。 合理才好。

所谓限制进程并不是指技术上限制进程。是指设计上合理设计而已。 什么叫合理设计又回到了前面那个问题，必须看你具体的业务。没有一个固定标准。

讲几条这次大会总结的经验（注意不是规范，是经验而已）：

1.  小消息大运算（yufeng）
这就代表如果你某个进程运算量过少的话，就用函数做算了，不要用进程。免得来回通讯开销过多；这条会降低你设计的进程数量

2.  当心进程过载（单个进程成为系统瓶颈）
如果某个进程需要服务于过多进程的话， 他就会过载。好比1000个小孩打一个小孩（yufeng） ， 由于erlang 不支持将一个小孩拥有1000个小孩的超能力，唯一的解决办法就是将其变为1000个小孩打1000个小孩（可以横拆或者纵拆，如果能拆得开的话）。 解决进程瓶颈。 这种情况就是增加进程数来解决

3.  当心慢速操作拖慢进程处理， 造成堵塞（xushiwei）
这种情况下，erlang 的解决方案就是创建新的进程去慢慢做那个慢速操作，让服务进程能够快速处理下一个请求。  这样的话也是增加进程数量
（xushiwei 的cerl 2.0 解决方案是这个服务协程下面再管理一套“子协程”，其实也是一回事）


总结下， 其实所有进程的设计都不是按照越多越好，越少约好的标准来考虑的， 而是根据业务实际特点来设计的。 该多少就多少。



Regards

老范

[Karl Ma]

看来大会里来真讲了不少好东西呀!

2009/11/9 老范 <fanyu...@gmail.com>

--
Karl Ma

[老范]

补充一句。 erlang 带来的好处就是设计进程可以 ：  根据业务实际特点来设计的。 该多少就多少。

而其他语言就得考虑进程开销等一系列问题，最后只能根据服务器能力来设计自己的进程数量，而不是根据业务合理性。 除非公司内有向xushiwei 和 lijie 这样的大牛模仿erlang 搞一套轻量级进程体系出来。


Regards


老范

2009/11/9 老范 <fanyu...@gmail.com>

[Linker M Lin]

On Nov 7, 9:43 pm, huangjiawei <ccl...@gmail.com> wrote:
> 看 erlang
> 程序设计的时候，多核编程。里面说进程不是越多越好。有时候要限制进程。但是没有给出限制进程的例子。请教各位。如何限制进程。限制进程以后。如何发挥erla ng的性能？

进程的数量应该和Actor概念的模型严格匹配，通过多node来提升承载能力。

[huangjiawei]

我只是不明白ERLANG如何限制进程数。我明白不是越多越好。但是具体怎么做。能不能有个大致思路？给个方向就行

2009/11/9 Linker M Lin <linker...@gmail.com>

[Zoom.Quiet]

2009/11/9 huangjiawei <ccl...@gmail.com>:

> 我只是不明白ERLANG如何限制进程数。我明白不是越多越好。但是具体怎么做。能不能有个大致思路？给个方向就行
>

这和erl 本身没有关系，是你的程序怎么写而已，
这次 ErloungIV 中提出的策略是尽量和现实对象 1:1 的配置进程;

> 2009/11/9 Linker M Lin <linker...@gmail.com>
>>
>> On Nov 7, 9:43 pm, huangjiawei <ccl...@gmail.com> wrote:
>> > 看 erlang
>> >
>> > 程序设计的时候，多核编程。里面说进程不是越多越好。有时候要限制进程。但是没有给出限制进程的例子。请教各位。如何限制进程。限制进程以后。如何发挥erla
>> > ng的性能？
>> 进程的数量应该和Actor概念的模型严格匹配，通过多node来提升承载能力。
>
>

--
http://zoomquiet.org 人生苦短? Pythonic!
金山常年招聘Py/C++人才! http://bit.ly/UoTV 简历直投俺就成;-)

[huangjiawei]

呵呵。就是请教一下这个程序怎么写？

2009/11/9 Zoom.Quiet <zoom....@gmail.com>

[Karl Ma]

奥？不明白问题是什么！

2009/11/9 huangjiawei <ccl...@gmail.com>

--
Karl Ma