5

私は非常に典型的な Web アプリケーションに取り組んでいます。ユーザー エクスペリエンスの主要コンポーネントは、サイトの所有者がフロント ページにインストールするウィジェットです。フロント ページが読み込まれるたびに、ウィジェットはサーバーと通信し、返されたデータの一部を表示します。

したがって、この Web アプリケーションには 2 つのコンポーネントがあります。

  1. サイト所有者がウィジェットを構成するために使用するフロント エンド UI
  2. ウィジェットの Web API 呼び出しに応答するバックエンド コンポーネント

以前は、これらすべてを PHP で実行していました。現在、Rails を試しています。これは 1 番目 (フロント エンド UI) にとって素晴らしいものです。問題は、#2 のウィジェット情報のバック サービングを効率的に行う方法です。クライアントの Web サイトの 1 つでフロント ページが読み込まれるたびに呼び出されるため、明らかにこれはフロント エンドよりもはるかに高い負荷です。

2 つの明白なアプローチを見ることができます。

A.並列スタック: Rails 以外のもの (たとえば、古い PHP ベースのアプローチ) を使用する並列スタックをセットアップしますが、フロント エンドと同じデータベースにアクセスします。

B. Rails Metal : Rails Metal/Rack を使用して Rails ルーティング メカニズムをバイパスしますが、API コール レスポンダーは Rails アプリ内に保持します。

私の主な質問:

  1. Rails/Metal は、このようなものに対する妥当なアプローチですか?

だけでなく...

  1. Rails 環境をロードするオーバーヘッドは依然として大きすぎますか?
  2. ほとんどの環境をバイパスして、Rails を使用して金属にさらに近づく方法はありますか?
  3. Rails/Metal のパフォーマンスは、単純な PHP での同様のタスクのパフォーマンスに近づきますか?

と...

  1. AとBの両方よりもはるかに優れた「C」オプションはありますか? つまり、バイナリにコンパイルされ、nginx または apache モジュールとしてインストールされる C コードの長さに進む前に何か?

洞察を事前に感謝します。

4

3 に答える 3

3

実際には最も精巧な答えではありませんが：

これにはメタルは使用せず、代わりにページ キャッシングを使用します。そうすれば、リクエストはウェブサーバーによって処理され、動的言語はまったく提供されません。リソースを作成したら、対応する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

詳細については、キャッシング ガイドを参照してください。

于 2010-04-10T04:38:35.467 に答える
2

パフォーマンスの問題が発生した正確な原因を突き止めた場合にのみ、Rack/Metal への機能の引き下げを開始します。最近のバージョンの Rails (特に 3) と Ruby では特に、スタック自体がボトルネックになることはほとんどありません。測定を開始し、実際の指標を取得して、慎重に最適化してください。

私の経験則: メトリクスがなければ、パフォーマンスの問題と考えられる解決策について賢明に推論することはできません。

私の経験では、問題はほとんどの場合、ビューとデータベースです。

Ryan が示唆するように、キャッシングは非常に効果的です。Rails リクエスト スタックの前でリバース プロキシを使用するようにアーキテクチャを移動して、さらに多くの機能を提供することもできます。Varnish のようなキャッシュは、非常に高いパフォーマンスを提供します。Rails には、リバース プロキシ ソリューションを促進するための etags と HTTP ヘッダーのサポートが組み込まれています。

他にすべきことは、db レイヤー自体を確認することです。ここではキャッシュが大いに役立つ可能性がありますが、ここでもいくつかの最適化が役立つ場合があります。Active Record の :include を賢明に使用することは、N+1 クエリの状況を回避するための優れたステップですが、Rails では、構成をほとんどまたはまったく構成せずに memcached をスタックにドロップする素晴らしいサポートがあり、優れたパフォーマンスの向上を実現できます。

于 2010-04-11T01:47:33.647 に答える
2

PHP は、リクエストごとに環境全体をロードします。プロダクション モードでは、Rails はサーバーの起動時に環境全体を 1 回ロードします。通常のコントローラ アクションの呼び出し中に、かなりの量の Ruby コードが実行されていることは確かです。ただし、本番モードでは、このコードは環境のロードに関連していません。また、通常の Rails コントローラー スタックの代わりに Rails Metal を使用すると、これらのレイヤーの多くが削除され、リクエストごとにさらに数ミリ秒の時間が節約されます。

于 2010-04-10T05:01:23.123 に答える