5

はじめにBackboneJS と Rails バックエンドで構築され
た (ほとんどの) シングルページアプリケーションがあります。

ほとんどのインタラクションは Web アプリケーションの 1 つのページで発生するため、ユーザーが最初にそのページにアクセスしたときに、基本的に、深く結合された 1 つの大きなクエリでデータベースから大量の情報を引き出す必要があります。

これにより、この 1 つのページで極端な読み込み時間が発生しています。

ロード時間

NewRelic は、私の問題のほとんどは 457 の個別の高速メソッド呼び出しが原因であると言っているようです。

高速メソッド呼び出し

これで、実行できる熱心な読み込みをすべて実行しましたが ( Bullet gemで確認しました)、まだ問題があります。

これらのメソッド呼び出しは、バックボーンを初期化するためにページに埋め込むために大量の JSON をシリアル化するために使用するRabl シリアライザーで発生する可能性が最も高いです。このすべてを理解する必要はありませんが、最大 457 のメソッド呼び出しを追加できると言えば十分です。

object @search
attributes :id, :name, :subscription_limit

# NOTE: Include a list of the members of this search.
child :searchers => :searchers do
  attributes :id, :name, :gravatar_icon
end

# Each search has many concepts (there could be over 100 of them).
child :concepts do |search|
  attributes :id, :title, :search_id, :created_at

  # The person who suggested each concept.
  child :suggester => :suggester do
    attributes :id, :name, :gravatar_icon
  end

  # Each concept has many suggestions (approx. 4 each).
  node :suggestions do |concept|
    # Here I'm scoping suggestions to only ones which meet certain conditions.
    partial "suggestions/show", object: concept.active_suggestions
  end

  # Add a boolean flag to tell if the concept is a favourite or not.
  node :favourite_id do |concept|
    # Another method call which occurs for each concept.
    concept.favourite_id_for(current_user)
  end
end

# Each search has subscriptions to certain services (approx. 4). 
child :service_subscriptions do
  # This contains a few attributes and 2 fairly innocuous method calls.
  extends "service_subscriptions/show"
end

だから私はこれについて何かをする必要があるようですが、どのアプローチを取るべきかわかりません。ここに私が持っている潜在的なアイデアのリストがあります：

パフォーマンス改善のアイデア

インターフェースの
ダムダウン おそらく、実際のデータの存在を必要としない、ユーザーに情報を提示する方法を思い付くことができます。なぜこれを絶対に行う必要があるのか​​ わかりませんが、Trelloなどの他の単一ページアプリには信じられないほど複雑なインターフェースがあります.

コンセプトのページ付け コンセプト
をページ付けすると、毎回データベースから抽出されるデータの量が減ります。ただし、劣ったユーザーインターフェイスを生成します。

キャッシュ
現時点では、ページを更新すると、検索全体が DB から再度抽出されます。おそらく、アプリの一部をキャッシュして、DB ヒットを減らすことができます。私が扱っているデータの多くは静的ではないため、これは面倒に思えます。

複数のリクエスト
JSON をページに埋め込まずにページを提供するのは技術的には良くありませんが、データを取り込まずにページを読み込んでからデータをフェッチすると、ユーザーは処理が速くなったように感じるかもしれません。

インデックス
すべての外部キーにインデックスがあることを確認する必要があります。また、インデックス (お気に入りなど) があると役立つ場所についても考えて追加する必要があります。

メソッド呼び出しを DB に移動
おそらく、ビュー レイヤーで実行した反復の結果の一部を DB にキャッシュし、計算する代わりにそれらを引き出すことができます。または、読み取り時ではなく書き込み時に同期することもできます。

質問
私が何に時間を費やすべきかについて何か提案はありますか?

4

2 に答える 2

1

これは、実際のユーザー インターフェイスを見ることができないと答えにくい質問ですが、最初のインターフェイスを表示するために必要な量のデータのみを読み込むことに焦点を当てます。たとえば、提示しているデータの一部を表示するためにユーザーがドリルダウンする必要がある場合、そのデータを最初のペイロードの一部としてロードするのではなく、オンデマンドでロードできます。検索には 100 もの "概念" を含めることができるとおっしゃいましたが、最初にそれらの概念をすべて取得する必要はないのでしょうか?

要するに、あなたの問題は実際にはクライアント側にあるようには思えません - サーバー側のコードが速度を落としているようです.複雑なクエリは、確実に必要になるまで。

于 2012-05-05T21:45:43.437 に答える
1

JS コードベースを、RequireJSのようなアセット ローダーを使用して動的にロードされるモジュールに分割することをお勧めします。こうすることで、ロード時に XHR がそれほど多く起動されなくなります。

特定のモジュールが必要な場合は、ページをロードするたびにではなく、適切なタイミングでロードして初期化できます。

コードを少し複雑にすると、各モジュールが開始および停止できるようになります。そのため、polling実行中のコードや複雑なコードがある場合は、モジュールを停止してパフォーマンスを向上させ、ネットワーク負荷を軽減できます。

于 2012-05-05T16:46:07.857 に答える