分享 Ruby - 响应 100W 的并发

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

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

共收到 16 条回复
96

不错不错

2622

EventMachine 👍

5173

里面有cometd实现

1723

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

4215

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

2376

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

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

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

1723

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

515

值得一试

1924

好东西

667

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

2376

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

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

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

个人粗略感受

239

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

667

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

2376

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

15楼 已删除
756

链接已经打不开了

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册