@rasefon EM 的语法其实和 nodejs 差不多，都很折磨人....c 可比 node 烦多了...

@lifuzho 是啊...比不过人家啊

@wxianfeng 尝试关注下这个，但是和 NGINX 整合在一起应该只适合很素的需求吧 @sevk ruby 2.0 感觉和 1.9 比不是颠覆性的升级，性能感觉提升不是特别明显

@kenshin54 结果是？

@jjym rainbows 的 server 就是基于 EM 的呀

@robbin 我实测的时候，内存峰值不到 60M，这个时候 GC 影响大么？这个真没什么经验..

自己尝试了下，用了你 robbin_site 下的 GC 参数，在只读取 1 个数据的情况下，从 400 req/s 提升到了 530 req/s

读取 113 个数据的情况下，从 17 req/s 提升到了 25req/s每秒

果然，GC 影响这么大...

@fredwu 果然差距巨大啊

@nickelchen 我看了下你的测试数据，大致对比了下单核性能，如果只查询一条数据，我在 Intel(R) Pentium(R) Dual CPU E2220 @ 2.40GHz的机器上大概可以做到 400 个请求每秒，单进程，但是 Node 可以做到 700+ 的请求每秒，我觉得你可以尝试下用 node 做一个同样功能的版本，我相信性能数据会让你吃惊的

@kenshin54 这个我知道呢，所以，我基于 EM 的 Reactor 机制重写了通讯的 socket，从某种角度上来说和 EMMongo 是类似的

@jjym 就是基于 EM::Connection 写的，

module EMMongoSocket
    BINARY_ENCODING = Encoding.find("binary")

    attr_reader :buff

    def initialize(opt = {})
      @buff    = ''.force_encoding(BINARY_ENCODING)
      @running = false
      @pool    = opt[:pool]
      @proc    = nil
    end

    def post_init
    end

    def add_processor(proc)
      @proc = proc

      unless @buff.empty?
        EM.next_tick { @proc.call(@buff) if @proc }
      end
    end

    def remove_processor(proc)
      @proc = nil if @proc == proc
    end

    def checkin
      @pool.checkin(self)
    end

    def receive_data(data)
      if data
        @buff << data

        unless @buff.empty?
          @proc.call(@buff) if @proc
        end
      end
    end

    def unbind

    end
  end

@luikore EMMongo 不支持 Replica Sets 啊，真是内牛满面，现在这个还不是瓶颈点，真的成为瓶颈点了也只能用 node 写了，功能还是满素的，只是有这么大的差距，不甘心啊....哈

@luikore 如果瓶颈在 EM 上，那么，基于 Fiber 和 socket 在尝试一个版本是不是效果会比 EM 好？

@jimrokliu ruby 的 VM 还是不够给力啊。。。虽然写起来很爽，但是，也就像 rails 一样，不能在 ruby 的温床里面不肯出来啊

@hhuai 传说中优化的没什么好优化的 V8 啊。。。

@jjym 是的，rainbows 的 backend 切换到了 Eventmachine 模式

@blacktulip 是啊，真不明白到底差在哪里。。理论上序列化和反序列化都是跑在 C 的栈上的。。差距还是这么大啊

mongoid 从 3.0 开始，已经使用自己的一套 API，叫做 moped, 之前的都是用的 mongo

[email protected]

@cgyy 不是，Fiber 是 Native 实现的，不是语法糖，运行意义而言，和 Thread 是一个层面的

启发很大，躺在 rails 的温床太久了...一些性能敏感的模块或许不适合使用 rails 实现吧，毕竟并发模型放在那里，适合 WEB 项目，不是 WebService 项目

@bhuztez 受教了!~

@SharpX 纳尼....Faye 不是实现了 SSE 的 backend 么..sse 的标准和 Faye 有啥关系...不明白...

@bhuztez XML 相对而 JSON 而言，构建一个层级的数据结构，会把原来的数据量扩大的更多，不是 XMPP 的问题，是 XML 的问题

@calebx 用这个协议的话可以考虑 Faye, 有这个协议的 Adapter

@kehao 去年为一个牌子做路演的时候，用的 XMPP 搭了一个游戏服务器，用的是本地服务器..一台服务器接两个设备，一天走了 2G 的流量....还是那个游戏没什么人玩的时候....

@bhuztez XMPP 流量大的地方在于它是用 XML 了...单个 STANZA 的数据量被 XML 扩大了好多倍...

测试了下之前的 beta 版本，发现启动速度快了许多，果然如其所说，require 的性能有了很大的提高

对于我们公司这种一个 rails app 下面挂了 20+ GEM 的来说，启动速度还是有了很大的提高了...

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

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

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

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

个人粗略感受