4 倍加速已经令人印象深刻，有时候你得到更多，到 20 倍。从我自己经验举个例子。我有一个三维 OLAP 多维数据集与 600k 数据行。我的程序做了切片和聚合。在 Ruby 中，它花费了 1G 的内存大约 90 秒完成。等价的 SQL 查询在 5 内完成。
2.3 优化 Unicorn
如果你正在使用Unicorn，那么以下的优化技巧将会适用。Unicorn 是 Rails 框架中最快的 web 服务器。但是你仍然可以让它更运行得快一点。
2.3.1 预载入 App 应用
Unicorn 可以在创建新的 worker 进程前，预载入 Rails 应用。这样有两个好处。第一，主线程可以通过写入时复制的友好GC机制(Ruby 2.0以上)，共享内存的数据。操作系统会透明的复制这些数据，以防被worker修改。第二，预载入减少了worker进程启动的时间。Rails worker进程���启是很常见的（稍后将进一步阐述），所以worker重启的速度越快，我们就可以得到更好的性能。
若需要开启应用的预载入，只需要在unicorn的配置文件中添加一行：
preload_app true
2.3.2 在 Request 请求间的 GC
请谨记，GC 的处理时间最大会占到应用时间的50%。这个还不是唯一的问题。GC 通常是不可预知的，并且会在你不想它运行的时候触发运行。那么，你该怎么处理？
首先我们会想到，如果完全禁用 GC 会怎么样？这个似乎是个很糟糕的想法。你的应用很可能很快就占满 1G 的内存，而你还未能及时发现。如果你服务器还同时运行着几个 worker，那么你的应用将很快会出现内存不足，即使你的应用是在自托管的服务器。更不用说只有 512M 内存限制的 Heroku。
其实我们有更好的办法。那么如果我们无法回避GC，我们可以尝试让GC运行的时间点尽量的确定，并且在闲时运行。例如，在两个request之间，运行GC。这个很容易通过配置Unicorn实现。
对于Ruby 2.1以前的版本，有一个unicorn模块叫做OobGC:
require 'unicorn/oob_gc'
use(Unicorn::OobGC, 1) # "1" 表示"强制GC在1个request后运行"
对于Ruby 2.1及以后的版本，最好使用gctools(https://github.com/tmm1/gctools):
require 'gctools/oobgc'
use(GC::OOB::UnicornMiddleware)
但在request之间运行GC也有一些注意事项。最重要的是，这种优化技术是可感知的。也就是说，用户会明显感觉到性能的提升。但是服务器需要做更多的工作。不同于在需要时才运行GC，这种技术需要服务器频繁的运行GC. 所以，你要确定你的服务器有足够的资源来运行GC，并且在其他worker正在运行GC的过程中，有足够的worker来处理用户的请求。
2.4 有限的增长
我已经给你展示了一些应用会占用1G内存的例子。如果你的内存是足够的，那么占用这么一大块内存并不是个大问题。但是Ruby可能不会把这块内存返还给操作系统。接下来让我来阐述一下为什么。
Ruby通过两个堆来分配内存。所有Ruby的对象在存储在Ruby自己的堆当中。每个对象占用40字节（64位操作系统中）。当对象需要更多内存的时候，它就会在操作系统的堆中分配内存。当对象被垃圾回收并释放后，被占用的操作系统中的堆的内存将会返还给操作系统，但是Ruby自有的堆当中占用的内存只会简单的标记为free可用，并不会返还给操作系统。
这意味着，Ruby的堆只会增加不会减少。想象一下，如果你从数据库读取了1百万行记录，每行10个列。那么你需要至少分配1千万个对象来存储这些数据。通常Ruby worker在启动后占用100M内存。为了适应这么多数据，worker需要额外增加400M的内存（1千万个对象，每个对象占用40个字节）。即使这些对象最后被收回，这个worker仍然使用着500M的内存。
这里需要声明， Ruby GC可以减少这个堆的大小。但是我在实战中还没发现有这个功能。因为在生产环境中，触发堆减少的条件很少会出现。
如果你的worker只能增长，最明显的解决办法就是每当它的内存占用太多的时候，就重启该worker。某些托管的服务会这么做，例如Heroku。让我们来看看其他方法来实现这个功能。
2.4.1 内部内存控制Trust in God, but lock your car 相信上帝，但别忘了锁车。（寓意：大部分外国人都有宗教信仰，相信上帝是万能的，但是日常生活中，谁能指望上帝能帮助自己呢。信仰是信仰，但是有困难的时候 还是要靠自己。）。有两个途径可以让你的应用实现自我内存限制。我管他们做，Kind（友好）和hard（强制）.