Ruby China

分享 Ruby - 响应 100W 的并发

huacnlee · 2013年02月21日 · 最后由 psvr 回复于 2014年08月19日 · 9984 次阅读

https://speakerdeck.com/slivu/ruby-handling-1-million-concurrent-connections

用的东西：

Espresso Framework - fast and easy to use.

Rainbows! Web Server - supports streaming and forking.

EventMachine - mature and stable I/O library for Ruby.

https://github.com/slivu/1mc2

38 个赞
无引用文章
ihlayy #0 2013年02月21日

不错不错

jjym #1 2013年02月21日

EventMachine 👍

i5ting #2 2013年02月21日

里面有 cometd 实现

ptmagic #3 2013年02月21日

@huacnlee ::EM 这种写法是什么意思呢？经常看到::EM 这种？

chenge #4 2013年02月21日

#4 楼 @ptmagic ::是顶层模块的意思吧。

killyfreedom #5 2013年02月21日

个人觉得这个没什么太大的意义...

毕竟..也只能处理 179 个请求每秒...另外的 999821 个连接要么在闲置，要么在等待...

想不到这么大的并发量和这么 低 的处理能力 (相对并发量来说) 可以在什么场景用到

ptmagic #6 2013年02月21日

#5 楼 @chenge 行我看看谢谢哈

kewin #7 2013年02月21日

值得一试

xiaogui #9 2013年02月22日

#6 楼 @killyfreedom 适合统计等不需要高实时系统。

killyfreedom #10 2013年02月22日

@xiaogui 相对统计而言，我不知道这样的做法会不会更好..

通过 Get 请求获取 nginx 的一个空的 gif, 然后后端接上 java 的 storm 做分析之后加入到后台 DB 毕竟 Nginx 处理静态文件的能力是非常强，远远不是几百这个数量级别的

而且不是高实时的系统的话，不知道长连接意义何在...

个人粗略感受

hlxwell #11 2013年02月22日

EventMachine 发现如果你没有一个好的 web 框架，你还得搭一大堆东西上去，比如 http header 解析，加上这些字符串解析类的东西后，ruby 又拖后腿了。然后就慢了下来了。

xiaogui #12 2013年02月22日

#11 楼 @killyfreedom 统计一般还会保存一些相关信息。当然可以拼接在 url 上，但总也比较麻烦。我说的只是畅想。 统计我们可以原始信息扔进 redis 队列里面，然后该次请求就结束。后台可以用多台机器的多个线程从 redis 队列里取原始信息，然后分别进行处理，保存到相应位置。

killyfreedom #13 2013年02月25日

@xiaogui 对于并发量高的情况下，个人认为不建议单个请求和 DB 相关...因为很快，DB 就会成为瓶颈..进程间交互次数越多，性能的损失越大

14 楼 已删除
psvr #15 2014年08月19日

链接已经打不开了

fahchen 在 依然是蛋疼的微信 API 提及了此话题。 04月03日 10:56
需要 登录 后方可回复, 如果你还没有账号请 注册新账号