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 就会成为瓶颈..进程间交互次数越多,性能的损失越大
链接已经打不开了