分享 Ruby - 响应 100W 的并发

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

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

不错不错

EventMachine 👍

里面有 cometd 实现

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

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

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

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

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

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

值得一试

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

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

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

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

个人粗略感受

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

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

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

15 楼 已删除

链接已经打不开了

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