2012-03-14 61 views
9

我有一個很多產品和其他內容的網上商店。目前我將所有內容加載到Application_Start的全局列表中,這需要15到25秒的時間。最佳實踐 - 在application_start中加載很多東西?

這使得網站真的很快,因爲我可以在O(1)時間獲得任何產品/內容。

但是,這是最佳實踐嗎?

目前我有一個不是VPS /專用服務器的webhotel,所以它隨時回收應用程序,這使得隨機訪問者的加載時間高達15-25秒(只有成爲一個更大的數字與更多內容)。這當然是完全不能接受的,但我想這將通過VPS解決。

這樣做的正常方法是什麼?我想像亞馬遜這樣的網上商店可能不會將他們的所有產品加載到一個巨大的列表中:-D

任何想法和想法將不勝感激。

+0

中小型網站可以接受。它可能無法很好地擴展到多個服務器。也取決於數據。 – 2012-03-14 18:42:05

+0

你使用的是什麼數據庫? – 2012-03-14 18:49:09

+0

我使用MSSQL作爲數據庫。當我們獲得50.000+種產品時,我還想要一個解決方案,而且這種方法可能不是可縮放的。:) – 2012-03-14 18:49:50

回答

6

看起來你已經回答了你的問題你的的情況「這當然是完全不能接受的」。

如果您的目標O(1)對單個產品的數據庫的正常請求可能是O(1),除非您需要在產品之間進行復雜的連接。考慮嘗試刪除所有預緩存邏輯並查看是否存在性能問題。您可以改用惰性緩存來限制啓動影響。

大型網站通常使用像MemcaheD這樣的分佈式緩存。

5

更具擴展性的設置是設置一個Web服務來提供網站在需要時調用的內容。 Web服務將需要緩存經常需要的內容以實現快速響應時間。

2

分離職責將幫助您擴展未來。

使用您當前的設置,您僅限於Web服務器的資源,並且像您所說的那樣,隨着您繼續添加更多產品,啓動時間將會失去控制。

如果您與SQL Server共享每個頁面請求的負擔,那麼您可以打開應用程序以允許它根據需要進行縮放。隨着時間的推移,您可能會決定添加更多的Web服務器,羣集SQL Server或完全切換到新的數據庫後端。但是,如果所有的負擔都在應用程序池上,那麼您將極大地限制自己。

+0

您能分享示例中的鏈接/代碼嗎? – Pankaj 2012-03-14 18:59:12

2

首先,15-20秒加載的數據太多的時間,所以我懷疑這種情況下

  • 該時間是編譯,而不是數據加載
  • 的數據是太多了,你完全內存
  • 您用來讀取數據的方法是很慢的
  • 的數據存儲速度太慢,或者是結構上的文本文件,它的讀取速度慢

我的意見是,你只需要在短時間內緩存少量需要使用的數據。由於某些原因,你描述它的方式並不是很好的做法。

  1. 如果您有許多池,您可以在所有池上讀取相同的數據,並且無需花費內存。
  2. 您緩存的數據不能更改它們 - 僅用於讀取
  3. 即使您緩存了一些數據,您仍然需要渲染頁面,並且存在實際需要製作緩存的位置渲染,而不是數據。

什麼和如何緩存。

  • 我們緩存最終的渲染頁面。
  • 我們還爲頁面和其他元素設置緩存給客戶端。
  • 我們從數據庫讀取和寫入數據,因爲他們來了,我們離開數據庫做緩存,他知道更好。
  • 如果我們緩存數據,那麼它們的數量必須很少,需要用於長循環,我們會避免多次數據庫調用。

另外我們緩存,因爲他們要求它,如果不使用很長時間,或內存需要空間這部分緩存消失。如果數據的某些部分來自許多表格的複雜組合,那麼我們製作一張臨時的平坦大表格,將所有數據連在一起,每一行都是一行一行。這張表是臨時的,如果我們需要太多的話,我們會創建第二個臨時數據庫文件來保存這部分數據。

數據庫讀取速度有多快?好的速度非常快,你不需要擔心,你需要檢查其他的延遲點,就像我說的完整的頁面渲染或頁面的某些部分。

你需要擔心的是一個好的數據庫設計,一種快速檢索數據的好方法,以及一個很好的優化代碼來展示它們。