rails metal(和rack)是实现高流量web服务api的好方法吗?

如果我确定了遇到任何性能问题的确切原因,我只会开始将功能拉到机架/金属上。特别是在最近的rails(特别是3)和ruby版本中,栈本身很少成为瓶颈。开始测量,获得一些真正的指标并明智地优化。

我的经验法则是:如果你没有度量标准,你就不能理智地思考你的性能问题和任何可能的解决方案。

根据我的经验,问题几乎总是:视图和数据库。

正如Ryan所建议的,缓存可以非常有效…您甚至可以移动您的架构,在您的rails请求堆栈前面使用反向代理来提供更多的功能。像缓存一样的清漆提供了难以置信的高性能。rails内置了对etag和http报头的支持,以促进反向代理解决方案。

另一件事是查看数据库层本身。缓存在这里可以走很长一段路,但是一些优化在这里可能也很有用。确保使用active record:include-sensibly是避免n+1查询情况的一个很好的步骤,但是rails中有非常好的支持,可以在很少或根本没有配置的情况下将memcached放入堆栈中,这可以提供出色的性能增益。

不是最详尽的答案,但是:

我不会使用metal,而是使用页面缓存。这样,请求将由web服务器提供服务,而根本没有动态语言。创建资源时清除相应的 index 页。一个非常基本的例子是:

class PostsController < ApplicationController
  caches_page :index

  def index
    @posts = Post.all
    respond_to do |format|
      format.html
      format.xml
    end
  end

  def create
    @post = Post.new(params[:post])
    respond_to do |format|
      if @post.save
        expire_page :action => :index
        format.html { redirect_to posts_path }
        format.xml
      else
        format.html { render :action => "new" }
      end
    end
  end
end

有关详细信息,请阅读 the Caching Guide .

php在每个请求上加载整个环境。在生产模式下,当服务器启动时,rails会加载整个环境一次。在正常的控制器操作调用过程中,肯定会执行大量的ruby代码。但是,在生产模式下,这些代码都与加载环境无关。使用rails metal而不是通常的rails控制器堆栈可以删除许多层,从而为每个请求节省额外的毫秒时间。