erlang, nodejs, go, python,

2012-05-11 19:50:13 +08:00
 myrual
服务器软件,支持3万个客户端同时在线,每个客户每分钟发3个1k的数据包,与服务器通信使用UDP。
用python+twisted+线程+线程间通信?
还是erlang?
还是nodejs?
还是go?

无论那种语言,我的想法是最好能针对每一个客户端启动一个线程,这样逻辑简单很多。
但是启动3万个线程,而且线程不退出,不知道那一个框架和语言可以在比较低的内存消耗和cpu使用量上实现

谢谢。
7200 次点击
所在节点    程序员
16 条回复
lfeng
2012-05-11 20:02:56 +08:00
erlang 比较靠谱吧。。。
eric_q
2012-05-11 20:09:57 +08:00
非阻塞……erlang吧,不过看了你另一个帖子,我觉得还是老老实实python吧
bhuztez
2012-05-11 20:12:23 +08:00
@eric_q 看具体应用啊。这个场景,明显 Erlang 简单,只要照着OTP风格依样画葫芦就可以了。
oldgun
2012-05-11 20:35:02 +08:00
用python的话建议eurasia
HowardMei
2012-05-11 20:36:44 +08:00
可以看看 http://mongrel2.org/ (+http://code.google.com/p/openpgm/ to support PGM/UDP)能不能满足你的需求,你可以直接用 任何语言(php/c/c++/java/ruby/python 只要 zeroMQ 支持即可)写 backend handler

用python 框架 http://brubeck.io 写web handler 也未尝不可

这个也没有多少 proven records, 但比 hack from scratch 要好那么一点点。

如果你一定要用 twisted,可以看看 http://cyclone.io/
virushuo
2012-05-11 20:41:21 +08:00
看看go的goroutines 和 channel,正是你需要的。
myrual
2012-05-11 20:52:03 +08:00
@HowardMei openpgm 在arm上无法编译。官方不支持。
@lfeng @virushuo @HowardMei @oldgun @bhuztez
非常感谢好心人。

另外我观察了目前得到的试验数据,基于UDP在实际网络情况中的糟糕表现,可能控制命令的传输还是要回到TCP上来。
zero暂时又回到视线范围内。
ayang23
2012-05-11 21:01:41 +08:00
3万客户端每分钟3个数据包是很简单的事情,不需要复杂化,介于有可能3万个客户端同时发来数据,做个异步处理或者队列就有必要了。差不多的框架性能上都能满足。
myrual
2012-05-11 21:12:47 +08:00
@ayang23 三万个TCP连接同时保持的话,是很大的问题么?
用twisted这样的框架是不是就够了?
ayang23
2012-05-11 21:17:21 +08:00
每分钟更新3个数据,没必要TCP持久连接。应该没问题。
jiyinyiyong
2012-05-11 21:22:49 +08:00
学 Node 但没深入.. 常说单线程非阻塞, 没发现在 CPU 和内存有优势.
reus
2012-05-11 22:45:29 +08:00
erlang的线程最轻量,所以个人感觉最经济
其实还有一个选择是openresty,国人写的基于nginx的框架 http://openresty.org/
作者的微博:http://weibo.com/agentzh ,如果有兴趣可以问下他看这种场景是否适合
notedit
2012-05-12 01:54:14 +08:00
据我对go的了解,一个goroutine 用来维持一个连接, 一个goroutine 大概占4k的空间。 go写并发的server简直就是利器(有很多好用的好用的api)
myrual
2012-05-12 07:31:42 +08:00
@ayang23 业务要求保持长链接,类似pushmail那样的
CMGS
2012-05-13 00:33:56 +08:00
其实我很想说……Gevent……
3W并发没达到过,我做过最高的压测大概是2W同时……
4 workers, gunicorn+gevent……
myrual
2012-05-15 20:56:25 +08:00
谢谢大家的讨论。 今天经过开会讨论,所有的客户端通过https访问服务器来传输各种命令和获取信息。 然后负载的问题交给iis,业务逻辑还是让it部门去干,他们依然可以使用他们最熟悉的asp.net。只要嵌入式设备能够完整实现https客户端就好,不要发了tcp连接建立,发送数据之后就断开连接。
这意味着我之前考虑的各种并发问题,通讯问题,tcp问题一去不复返。
我只要专心做好一个服务模块就行了。 这个模块对外提供http服务,让别的服务器通过http来发送和获取数据。 然后我只要把一些从UDP通讯中获取的简单数据通过http服务返回给查询的客户端。
我想,这是一个必定可以工作的方案,而且似乎是相对成熟的方案,毕竟基于http,有IIS。

我只是想,为什么有人要发明那些zeromq,erlang来进行发送大规模消息呢?
http发送有什么明显的缺点么?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/35526

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX