要做 web im，Node.js 与 Eurasia 比较
生生
Google 时知道了 Eurasia，根据介绍知道了几个关键词：百万用户，长连接，Python，专为 Web IM，游戏而生。酷。
我现在想用 Eurasia 去实现这个应用，接触 Python 不久，有几个问题：
1. Eurasia 与 Node.js 比较有什么优势？（优势一，我更喜欢 Python）
2. 必须要用 Statckless Python 才能达到百万用户同时在线的性能吗？
3. 如果聊天记录要存到 MongoDB，网络 IO 会是瓶颈吗？怎么解决比较好。
4. 这里所说的长连接是一直连接吗？还是只是超时时间更长？
lee Alexander
--
您收到此邮件是因为您订阅了 Google 网上论坛的“eurasia-users”论坛。
要向此网上论坛发帖，请发送电子邮件至 eurasi...@googlegroups.com。
要取消订阅此网上论坛，请发送电子邮件至 eurasia-user...@googlegroups.com。
若有更多问题，请通过 http://groups.google.com/group/eurasia-users?hl=zh-CN 访问此网上论坛。
--
Alexander.Li
+86 15308006505
mail: superp...@gmail.com/superp...@hotmail.com
site:http://alexander-lee.cnblogs.com
老光
文档中的简单示例已经比较强大,目前有几个疑问:
1.当用户关掉IE窗口或离开该页面(访问其他网址)的时候,服务器端只有在尝试向这个httpfilewrite的时候,才会引发Disconnect?而不是马上获知用户离开?
当然正常情况可以用onunload来异步提交一个用户离开的请求,只是其他时候不好办.
2.我前面发邮件问过,可能那大大最近不常在.本群曾有大大尝试用eurasia写多人在线聊天室,不知成果如何了?想共享一下思路最好了.
高度关注本邮件咯,只是最近不得空去整3.1.
----- Original Message -----
From: "沈崴" <wile...@gmail.com>
To: "eurasia-users" <eurasi...@googlegroups.com>
Sent: Wednesday, February 23, 2011 9:38 AM
Subject: [eurasia-users] Re: 要做 web im，Node.js 与 Eurasia 比较
> 1. 我没有深入了解过 node.js，只能简单提取一下 eurasia 和 node.js
> 它们之间一些表面上的区别。
>
> 首先 eurasia 是基于 python 的；而 node.js 是基于 javascript 的。
>
> 然后 node.js 是异步模型；虽然 eurasia 底层一样是异步的，但你不需要
> 关心事件、回调之类的异步逻辑，底层会自动处理。
>
> <异步逻辑（诸如 "node.js"）>
> def on_read(data):
> print data
> sock.read(1024, on_read)
>
> <eurasia>
> print sock.read(1024)
>
> 最后如果 node.js 是纯异步的话，并发和性能上与 eurasia 应在同一层次。
>
> 2. eurasia 3.1 不依赖于 stackless python，eurasia 3.0 需要。
>
> 3. 阻塞式的数据库 IO 对异步服务器都会是瓶颈，对 eurasia 和 node.js
> 都是这样的。如果数据库有纯 python 实现的接口，eurasia 就可以直接使用
> 而不会造成性能问题，否则就需要编写一定的 “驱动” 将阻塞式数据库接口异步
> 化。详见 eurasia 文档数据库部分。
>
> 当然在数十万的长连接情况下，最好避免有数据库 IO 产生。聊天记录比较接近
> 日志文件的技术。
>
> 4. 这里说的长连接是一直连接的，和比较长的超时时间是一件事情。
> 在 eurasia 中可以非常细粒度的控制超时，甚至对每一个读写操作进行超时控制。
>
> sock.read(1024, timeout=10.)
> sock.write('hello world!', timeout=15.)
> 沈崴
沈崴
> http所谓的长连接本质上就是超时时间长，100W的活动TCP连接怕是很玄，因为按照一个Connection
> 2M的内存消耗来看，100W的活动TCP连接光是内存都吃不消拉
Alexander 提到的这点非常重要，随着连接数的上升内存肯定会很快耗尽。
同时 CPU 以及网络压力都是非常大的，到这个量级的程序和普通应用是有
很大区别的。
我们在此类应用中，对单连接的内存内存占用，以及系统许多部分都是经过
专门优化的。这可能需要一定的专业知识和经验。
沈崴
> OY,我也是一直比较关注用Eurasia来写web im,并在此基础上扩展.
> 文档中的简单示例已经比较强大,目前有几个疑问:
> 1.当用户关掉IE窗口或离开该页面(访问其他网址)的时候,服务器端只有在尝试向这个httpfilewrite的时候,才会引发Disconnect?而不是马上获知用户离开?
> 当然正常情况可以用onunload来异步提交一个用户离开的请求,只是其他时候不好办.
>
> 2.我前面发邮件问过,可能那大大最近不常在.本群曾有大大尝试用eurasia写多人在线聊天室,不知成果如何了?想共享一下思路最好了.
>
> 高度关注本邮件咯,只是最近不得空去整3.1.
看起来 web im 已经是 eurasia 的热门应用了。关于多人在线聊天室，
eurasia team 最近倒是有一点点简单的代码，等我们花点时间整理以后
贴上来吧，呵呵。
沈崴
它们之间一些表面上的区别。
首先 eurasia 是基于 python 的；而 node.js 是基于 javascript 的。
然后 node.js 是异步模型；虽然 eurasia 底层一样是异步的，但你不需要
关心事件、回调之类的异步逻辑，底层会自动处理。
<异步逻辑（诸如 "node.js"）>
def on_read(data):
print data
sock.read(1024, on_read)
<eurasia>
print sock.read(1024)
最后如果 node.js 是纯异步的话，并发和性能上与 eurasia 应在同一层次。
2. eurasia 3.1 不依赖于 stackless python，eurasia 3.0 需要。
3. 阻塞式的数据库 IO 对异步服务器都会是瓶颈，对 eurasia 和 node.js
都是这样的。如果数据库有纯 python 实现的接口，eurasia 就可以直接使用
而不会造成性能问题，否则就需要编写一定的 “驱动” 将阻塞式数据库接口异步
化。详见 eurasia 文档数据库部分。
当然在数十万的长连接情况下，最好避免有数据库 IO 产生。聊天记录比较接近
日志文件的技术。
4. 这里说的长连接是一直连接的，和比较长的超时时间是一件事情。
在 eurasia 中可以非常细粒度的控制超时，甚至对每一个读写操作进行超时控制。
sock.read(1024, timeout=10.)
sock.write('hello world!', timeout=15.)
On 2月22日, 上午8时51分, 生生 <liuzheny...@gmail.com> wrote:
--
沈崴
Jiahua Huang
Zoom.Quiet
> 沈游侠万岁～
>
板载!
准备指定为蟒营学生作品的基础框架了!
--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet
开: http://code.ijinshan.com/
豆: http://www.douban.com/group/zoomquiet
书: http://code.google.com/p/openbookproject
蟒: http://code.google.com/p/kcpycamp/wiki/PythoniCamp
lee Alexander
--
您收到此邮件是因为您订阅了 Google 网上论坛的“eurasia-users”论坛。
要向此网上论坛发帖，请发送电子邮件至 eurasi...@googlegroups.com。
要取消订阅此网上论坛，请发送电子邮件至 eurasia-user...@googlegroups.com。
若有更多问题，请通过 http://groups.google.com/group/eurasia-users?hl=zh-CN 访问此网上论坛。
Zoom.Quiet
> 其实我倒是很想问问沈大如何回避GIL充分利用多核计算能力来着
>
目前简单的作法是多进程,用MQ 进行協同...
liuznet
沈崴
> 1 个连接 2M？那 4G 内存才 2048 个？!!
虽然在没有做任何优化的情况下一个 python socket 占用的内存确实较多，
但好像并不会有 2M 这么多，4G 内存应该也可以达到百万句柄。这个测试做
得比较久了，已经记不大清了。但随着连接数的上升，内存压力会比较大。
Python 服务器在运行过程中，确实会发生内存不断上升的现象，减去启动时
的初始内存，每个连接平均下来 2M 是完全可能的。除去一些预分配的情况，
更多时候是因为内存没有回收。
服务器中的 socket 对象是很容易发生循环引用等情况的，引用计数就会失效
所以对应用服务器来说这是一种比较常见的情况。垃圾回收开始工作后这些内存
是会自动回收的。
不过并发要求比较高的服务器，应该避免使用垃圾回收机制。比如在 eurasia
中在编码中避免产生循环引用的情况，引用计数可以有效即时回收内存，因此
情况就要好很多。
沈崴
> 在 2011年2月23日 下午1:08，lee Alexander <superpower...@gmail.com> 写道：> 其实我倒是很想问问沈大如何回避GIL充分利用多核计算能力来着
>
> 目前简单的作法是多进程,用MQ 进行協同...
具体说，启动多个 eurasia 服务器，每个服务器进程对应一个 cpu 和 cpu 核心。
然后使用 iptables（或 lvs）进行负载均衡（比如，端口负载均衡）。
多个服务器进程间，进行协同的方法就比较多了。
lee Alexander
--
您收到此邮件是因为您订阅了 Google 网上论坛的“eurasia-users”论坛。
要向此网上论坛发帖，请发送电子邮件至 eurasi...@googlegroups.com。
要取消订阅此网上论坛，请发送电子邮件至 eurasia-user...@googlegroups.com。
若有更多问题，请通过 http://groups.google.com/group/eurasia-users?hl=zh-CN 访问此网上论坛。
沈崴
> 沈大能给个思路不呢，比如在多个Eurasia进程之间广播消息
这个解决方案比较多，方案细节也比较多，说起来比较困难。其实就和进程间通信是一样的。
这里我试着给一个 quick and dirty 的办法，一下子也讲不清楚，也就提供点思路吧。
1) 有多个（eurasia）前端服务器 frontend
2) 创建一个广播服务器 broadcast
每个前端服务器启用一个“线程”（greenlet 协程）通过 socket 连接到广播服务器。
socket 将一直处于等待广播服务器返回信息的状态，一有信息来立即在本服务器内转发
然后继续等待下一条广播。
赖勇浩
> 沈大能给个思路不呢，比如在多个Eurasia进程之间广播消息
0mq
--
web site：http://laiyonghao.com
twitter: http://twitter.com/laiyonghao
Zoom.Quiet
也就是说用一个MQ 作消息总桟,所有 应用服务持久连接到MQ 中进行实时的消息推入?!
- 嗯嗯嗯,同主机的多应用进程,也可以通过多个 socket 长连接持久接入
- 分布式的其它后续/异步处理应用,也可以近乎实时的从 MQ 中提取任务进行处置
关键是:
+ MQ 自动处理了超期等任务调度
+ MQ 智能均衡了任务争抡的调度
+ MQ 如果没有安全持久化任务队列的功能,得自个儿实现!否则 MQ 就是一个关键单点了...
--
人生苦短, Pythonic! 冗余不做,日子甭过!备份不做,十恶不赦!
俺: http://about.me/zoom.quiet