2012-05-05 214 views
5

介紹
我有一個(主要)單頁application與BackboneJS和Rails後端構建。因爲大多數交互發生在webapp的一個頁面上,所以當用戶第一次訪問頁面時,我基本上必須從一個大的深度連接查詢中將大量信息從數據庫中提取出來。如何提高單頁面應用程序的性能?

這導致我在這一頁上有一些相當極端的加載時間。

load times

NewRelic的似乎是告訴我,我的大部分問題都是因爲個人457所快速方法調用。

fast methid calls

現在我已經做了所有的預先加載,我可以做(我與Bullet gem選中),我仍然有一個問題。

這些方法調用很可能發生在我的Rabl序列化程序中,我使用它來序列化一堆JSON以嵌入到初始化Backbone的頁面中。你不需要了解所有這些,但足以說它可以加起來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)具有令人難以置信的複雜界面。

概念分頁
如果我概念分頁,它會減少每次從數據庫中提取的數據量。儘管如此,產品將會劣質用戶界面。

緩存
目前,刷新頁面只是將整個搜索從數據庫中提取出來。也許我可以緩存部分應用程序以減少數據庫訪問次數。這似乎很混亂,雖然因爲我處理的數據並不多。

多請求
這在技術上是壞的服務頁面而不嵌入JSON到頁面,但也許用戶會感覺事情正在發生更快,如果我加載頁面無人居住,然後獲取數據。

索引
我應該確保我所有的外鍵都有索引。我還應該嘗試考慮有助於建立索引的地方(如收藏夾?)並添加它們。

將方法調用到數據庫
也許我可以將我在視圖層中進行的迭代的一些結果緩存到數據庫中,然後將它們拉出而不是計算它們。或者我可以在寫作而不是在閱讀上同步。

問題
有沒有人有什麼建議,我應該花什麼時間?

回答

1

這是一個很難回答的問題,卻無法看到實際的用戶界面,但我只會專注於只加載顯示初始界面所需的數據。例如,如果用戶不得不向下鑽取以查看您正在呈現的一些數據,則可以按需加載該數據,而不是將其作爲初始有效載荷的一部分加載。你提到搜索可能有多達100個「概念」,也許你不需要最初獲取所有這些概念?

底線,它聽起來不像你的問題真的在客戶端 - 聽起來你的服務器端代碼正在放慢速度,所以我會探索你可以做些什麼來獲取更少的數據,或推遲複雜的查詢,直到他們肯定需要。

1

我建議將你的JS代碼庫分離成使用像RequireJS這樣的資產加載器動態加載的模塊。這樣你就不會有太多的XHR在加載時觸發。

當需要特定的模塊時,它可以在適當的時間加載和初始化,而不是每次加載頁面。

如果您稍微複雜一點,每個模塊都應該能夠啓動和停止。因此,如果您有任何polling發生或複雜的代碼執行,您可以停止模塊以提高性能並減少網絡負載。

+0

雖然我同意優化資產交付是提高績效的重要一步,但我不認爲這是我在這裏遇到的主要問題。雖然應用程序中有一串JS,但它被壓縮,縮小並以大約100kb的速度到達。它也應該被緩存在客戶端,這樣重複訪問者的加載成本就會降到最低。 –