0

私は基本的に has_many Pages のドキュメント モデルを持っています。また、一連のドキュメント (例: 300) を列挙し、各ページのボタンを作成する必要があるビューがあります。(テーブルを並べ替えたり検索したりできるように、DataTables jQuery プラグインを使用してクライアント側でページネーションを行いたい)。問題は、各ドキュメントの各ページのすべてのボタンを列挙しようとすると、レンダリングに 10 秒以上かかることです。これは役に立ちません。

この種のネストされたコレクションのレンダリングを高速化するための「トリック」はありますか? ドキュメントごとにフラグメントをキャッシュするだけでよいでしょうか (フラグメントは、一度作成されるとあまり変化しません)。それとも、Rails パーシャルにとってこれは単に悪い状況ですか? DataTables のページネーションの一部としてクライアント側のレンダリングを行うのが最善の策でしょうか?

編集：N + 1クエリの問題が発生しないように、関連付けを既に含めていますが、それは問題ではありません。そして、キャッシュを試してみましたが、このインデックス ページはいくつかのドキュメントが追加されるたびに頻繁にリロードされるため、すべてのパーシャルの完全なキャッシュを再構築する必要がないため、今のところそれが私の解決策のようです。

4

1 に答える 1

0

キャッシュがすぐに必要になるのは、コードの匂いのようです。推測する代わりに、プロファイリングを試しましたか? (例: http://hiltmon.com/blog/2012/02/27/quick-and-dirty-rails-performance-profiling/ )

gem 'ruby-prof'

プロファイラーを定義します。

# /lib/development_profiler.rb

class DevelopmentProfiler
  def self.prof(file_name)

    RubyProf.start
    yield
    results = RubyProf.stop

    # Print a flat profile to text
    File.open "#{Rails.root}/tmp/performance/#{file_name}-graph.html", 'w' do |file|
      RubyProf::GraphHtmlPrinter.new(results).print(file)
    end

    File.open "#{Rails.root}/tmp/performance/#{file_name}-flat.txt", 'w' do |file|
      # RubyProf::FlatPrinter.new(results).print(file)
      RubyProf::FlatPrinterWithLineNumbers.new(results).print(file)
    end

    File.open "#{Rails.root}/tmp/performance/#{file_name}-stack.html", 'w' do |file|
      RubyProf::CallStackPrinter.new(results).print(file)
    end
  end
end

あなたのビューロジックをラップしてください...

DevelopmentProfiler::prof("render-profiling") do
  # Your slow code here
end

編集 - 追加の考え: モデルのデータは変更される可能性が低いため、レンダリング コストを一度消費する方がよい場合があります。after_save コールバックでレンダリングされたページ全体を静的に生成できます。その後、後続のリクエストに対してその単一のファイルを提供するだけです。

より伝統的なキャッシュを請求することが大きな不便ではない場合でも、これは価値があるよりも問題になる可能性があります.

于 2013-04-24T15:27:36.617 に答える