Rails Metal（＆Rack）是實現高流量Web服務api的好方法嗎？

Question

我正在研究一個非常典型的Web應用程序。用戶體驗的主要組件是網站所有者將在其首頁安裝的小部件。每當他們的首頁加載時，小部件會與我們的服務器通話並顯示一些返回的數據。

因此有兩個組件來此Web應用程序：

1. 站點用戶使用來配置他們的小工具，響應控件的Web API調用
2. 後端組件前端UI

以前我們所有的這些都在PHP中運行。現在我們正在嘗試使用Rails，這對於＃1（前端UI）來說太棒了。問題是如何有效地做到＃2，小部件信息的後臺服務。很明顯，這比前端的負載要高得多，因爲每當我們的客戶的某個網站上加載前臺頁面時就會調用它。

我可以看到兩個明顯的方法：

A. 並行堆棧：設置使用比其他軌道的東西（如我們的老PHP爲基礎的方法），但訪問同一個數據庫前平行堆結束

B. Rails的金屬：使用Rails的金屬/機架繞過Rails的路由機制，但保留Rails應用程序中的API呼叫響應

我的主要問題：

1. Rails/Metal是一種合理的方法嗎？

而且...

將在加載Rails環境仍然過重的開銷？

有沒有辦法讓Rails更接近金屬，繞過大部分環境？

請問Rails/Metal性能是否接近直接PHP的類似任務的性能（只是在這裏尋找球場）？

而且......

是否有會比A和B都好得多一個 'C' 的選項？也就是說，在將C代碼的長度編譯爲二進制文件並將其安裝爲nginx或apache模塊之前？

在此先感謝您的任何見解。

Answer 1

如果我確定遇到任何性能問題的確切原因，我只會開始將功能降至Rack/Metal。特別是在Rails（特別是3）和Ruby的最新版本中，堆棧本身幾乎不是瓶頸。開始測量，獲得一些真實的指標並明智地進行優化。我的經驗法則：如果你沒有指標，你不能智能地推理你的性能問題和任何可能的解決方案。

我的經驗中的問題幾乎總是：視圖和數據庫。

正如Ryan所說，緩存可以非常有效......您甚至可以將您的體系結構移動到您的Rails請求堆棧前使用反向代理來提供更多功能。像Varnish這樣的緩存提供了令人難以置信的高性能。 Rails內置了對etags和HTTP頭的支持，以促進逆向代理解決方案。

另一件事是看看db層本身。緩存在這裏可以走很長的路，但是一些優化在這裏也可能有用。確保你使用Active Record's：明智地包含是避免N + 1查詢情況的一個很好的步驟，但Rails支持非常棒的將memcached放入堆棧，只需很少或不需要配置，這可以提供出色的性能收益。

Answer 2

不是真的最詳盡的答案，但：

我不會用金屬對於這一點，我會用頁面緩存來代替。這樣，這些請求將由網絡服務器提供，並且根本沒有動態語言。當您創建資源時，請清除相應的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。

Answer 3

PHP在每個請求中加載整個環境。在生產模式下，Rails在服務器啓動時加載整個環境一次。在正常的控制器操作調用期間，肯定會執行相當數量的Ruby代碼。但是，在生產模式下，這些代碼都不涉及加載環境。使用Rails Metal而不是通常的Rails控制器堆棧會刪除多個這些層，每個請求會節省幾個額外的毫秒時間。