楼主，继续给你优化建议哈：

ruby 的 json gem 性能其实是比较一般的，建议你换成 oj，估计还能整体提升 10% 的性能。

另外，如果你不怕麻烦的时候，可以到 github 上找找 ruby2.0 的性能补丁，反复测试测试各种参数各种补丁，运气好的话，还能提升 30%。

不过 ruby 真的没有必要和 node 比较。node 那种嵌套回调不适合写复杂逻辑，非常反人性，两者应用场景有差别。个人看法：n 年以后，Go 会消灭 node，不信等着看。

这数据对比还好吧。node 的强项就是 IO 并发，做这种测试其实就是测 IO 并发，你的 node 性能是 ruby 的 3 倍，说明 ruby 已经很不错啦。而 ruby 本身在 IO 方面就算传统弱项，这个差距在我看来真的算很小了。

另外你如果调整一下 ruby 的 GC 参数，还能够提高性能 50-100%。

我当年玩 webwork2 的时候，就觉得 OGNL 迟早出事，特别是那个 ParametersInterceptor，虽然自动创建对象，自动匹配对象属性赋值了，但危险性比 Rails 的 AR 的 update_attributes 还要高。

你看下这个 controller： https://github.com/robbin/robbin_site/blob/master/app/controllers/home.rb

就是你想要的，直接定位到根路径的。

秘诀就是这行：

RobbinSite.controllers do

不要定义 controllers 的命名空间，就会直接定位到根路径

get :index do @blogs = Blog.order('id DESC').page(params[:page]) render 'home/index' end

这个方法就是访问整个网站首页。

#15 楼 @helloqidi 没有遇到过。

Rails 升级太痛苦了，Rails 太笨重了，我已经放弃 Rails 了，解脱了。

web app 我就用 padrino，web api 我就用 sinatra，感觉很舒服。

透露一点线索哈，林芷薰 的本尊网络 ID 是 5 个字母，有一个形象的念法：鸡鸡咔嚓

看他的博客，我感觉他离职，可能那个公司真的有问题，不单纯是王垠自己的问题。我感觉王垠的问题是人际沟通方面有性格缺陷，团队合作方面差，但是如果公司真的如他描述的那样，“误用”Agile，行死板的流程化管理，换了我，也会走。

BTW: 现在国内"Agile"都臭大街了，和很多公司的误用是分不开的。

#14 楼 @quakewang 太坏了，勾引小白黑客阿。

#6 楼 @quakewang 你终于改成 unicorn 了。

#3 楼 @zerolin 没用 Rails，只用了 ActiveRecord 访问数据库。

我有一个超简单，但项目结构完整的测试 demo： grape on rainbows

很好！Ruby 从语法上来说已经足够 OK 了，现在差的就是虚拟机性能，以及多核并行的支持，看来 Matz 先生对 Ruby 未来的发展应该补足的功课是非常清楚的，那就让我们期待 Ruby2.1 的分代垃圾回收和多核并行的支持吧。

#51 楼 @Magic COW 是使用 Passenger/Unicorn 的时候，子进程会共享父进程的共享内存区 (主要是加载 Rails 框架那部分内存)。你在单纯的 ruby 进程上看不到减少，但服务器总物理内存会节省。

你可以用 gc-cow.rb 这个脚本测试一下就知道了，使用 Ruby2.0 的时候，fork 出来的子进程的 Private 内存占用明显下降。

#49 楼 @Magic 上面有人建议升级 ruby1.9.3 到 ruby2.0，这个建议也很靠谱。我刚刚测试过了，ruby2.0 的向下兼容 1.9.3 非常好，可无痛升级，而且 2.0 默认打开了 copy-on-write，多进程情况下可共享框架加载的内存，大约能节省 30% 的物理内存占用。

你的问题不在于单个 ruby 进程占用多少内存，而在于应该尽量少开进程的情况下，尽可能多的提高系统并发性能。

在 8 CPU (1x priority) 的服务器上，你开太多进程对提高并发性能没有多少帮助，建议如下：

1、nginx 开 1 个 worker 就行了，开 4 个没必要 2、既然是 API Server，就扔掉 Rails，直接用 Passenger/Unicorn/Rainbows 跑 grape，进程内存会节省很多，我估计能从 100MB 下降到 60MB 左右。 3、少开点进程，最多开 4 个 ruby 进程，观察一下请求的 IO 并发状况，如果并发不高，用 unicron 即可，如果并发高，可以改用 rainbows 跑多线程 4、如果你需要更高的 IO 并发，可以改用 goliath 跑 grape，内存不会更节省，但是并发性能会进一步提高 5、如果你不怕麻烦，可以把操作系统换成 32bit 的，能很大程度上节省内存 (缺点就是内存不能超过 4G)

#2 楼 @hooopo 你现在跑到哪里去了？

你可以换成 rainbows 看看。rainbows 也是多线程，但是 code base 和 unicorn 是一样的，我用下来很稳定。

#13 楼 @flyerhzm IO 占的比例很低的话，我测试下来，对比 unicorn 的确会稍慢一点。

但是之前大量实际应用，多进程比较大的问题就是很容易遭遇高并发的 DOS 攻击，不得不使用 IP 防火墙的方式避免出现进程被阻塞的情况。用多线程，这方面的问题就好很多了。

#42 楼 @iamroody 你换成 rainbows 比对一下，如果 rainbows 每个 worker 也增长到 500mb，那就是你程序内存泄露了，如果 rainbows 内存不高，说明 puma 有问题。

我自己对比观察下来，确实发现 puma 长期运行，内存占用似乎比 rainbows 高一些。

太牛 X 了，我对楼主佩服的五体投地！

#20 楼 @vincent GIL 只对纯 ruby 的内存运算有效，一旦有 IO 调用，CPU 就是阻塞等待状态，GIL 就解锁了，这个时候线程会释放 CPU 资源的。

#9 楼 @cgyy 用 em 写，会比 fiber 更快，但是 em 那种回调写法和 node.js 一样难用，而且库和第三方项目兼容性问题也很大。

#16 楼 @xwf286 Rails 我没有测试过，理论上来说是支持的，Rails3.2 多线程还是有些问题，Rails4.0 估计应该没问题了，不过 Rails4.0 我还没有使用，所以没有测试过。

我测试比较多的是 sinatra/padrino，多线程肯定是没有问题的，非常稳定。

#7 楼 @xwf286 你说的这种情况，就是接近 4，因为一旦调用外部 IO 操作，当前线程就会释放 CPU 内核控制权，另外一个线程就会获得 CPU 资源。

多核就用多个进程就好了，没坏处。用单一进程跑多核，GC 会成为一个巨大的瓶颈的。

#5 楼 @cgyy 和执行时间长短无关，只要有 IO 操作，就会放弃 CPU 控制权。如果是纯 CPU 运算的话，那就和单进程没区别了，IO 比例越高，fiber 并发性能越好。