我正在開發一個社交網站。什麼是緩存的正確信息？什麼是頁面加載時間？
從項目的第一天開始就一直在考慮可擴展性，我很好地調整了網站和查詢以盡我所能。
但是;某些頁面數據量非常大，我不太確定它們是否儘可能快地加載，因此我正在考慮實施分佈式緩存解決方案。
但不是很確定我應該緩存什麼，而不是緩存。或者，如果當前頁面加載時間爲1秒是好還是壞。
最重的查詢是抓取成員信息這個查詢獲取所有成員的信息和任何與他們有關的信息，例如在本網站的情況下，他們的目標，博客類型的條目，鼓勵，照片，狀態更新（如Twitter），博客信息用於交叉輸入）等等。
無論如何，我應該緩存這些信息嗎？你認爲1秒的頁面加載時間是否相當快？一些頁面在4-6秒之間不到一秒鐘。
如果可能的話，我會在應用程序的每一層都實現緩存。
您可以在最高級別緩存頁面，在代碼級別緩存對象，並確保數據庫在最低級別正確緩存查詢和關鍵數據。
根據您需要緩存的內容，任何將被重複訪問的對象都應該被緩存，尤其是那些不太可能經常更改的對象。只有編輯後才能重置該對象的緩存。 （請謹慎對待經常更新的緩存對象，因爲幾乎每次加載都會取代緩存的不斷循環會降低性能而不是增強性能）
對於衡量性能，我不會考慮單個頁面需要多長時間加載，但谷歌的一些性能測量工具，因爲你真的需要測試每個頁面在壓力下執行的速度。例如，您的用戶信息頁面可能不是最大的緩存目標。你應該專注於使用率最高的頁面。
爲什麼在不需要時實施緩存？這只是給應用程序帶來了額外的複雜程度。如果確定需要緩存，我一次只能處理一層。 – 2008-10-20 19:55:00
我也會對過度緩存感到害羞。這只是要求數據完整性問題。你打開這扇門的那一刻也是你必須擔心（在緩存BO的情況下）實現版本控制。最好一次拿一層。 – 2008-10-21 03:34:33
網頁加載問題已經被問：
什麼被認爲是一個很好的響應時間，動態，個性化的Web應用程序？
在高速緩存方面，您必須測量每次加載數據和從高速緩存加載所花費的時間。緩存越大，效果越差。所以你不想在緩存中加載太多的數據。我們在這裏使用的是一個滾動緩存，一旦我們達到緩存大小限制，最近最少使用的數據將被丟棄。然後根據實際表現結果調整限制。
對於用戶配置文件特定數據，儘可能多地存儲在FormsAuth票證/ cookie中。緩存（HttpContext.Current.Cache）用戶特定的項目將需要每個用戶的服務器上的X資源，與會話相同（但頭痛較少）。如果您可以儘可能多地將其卸載到用戶Ticket或Cookie（如4K）中，那麼您將在縮放時真正幫助您的服務器性能。
您應該只檢索頁面所需的信息位。例如，如果您正在加載博客數據，請勿加載照片。它有更多的工作，但是如果你想擴展，你將不得不分析每個頁面的需求。
確保您瞭解數據庫查詢緩存（執行計劃重用），對象緩存（Httpcontext.Cache）和頁面緩存（Response.Headers [Expires]）之間的差異。
典型的回答是：這是很少更新
在你的情況下，你可以緩存一切在平面文件（例如每個用戶一個文件），並銷燬一個用戶緩存文件，只要有相應的更新。如果緩存文件不存在，則在顯示相關內容之前創建它。
現在關於加載時間（可根據用戶的位置是非常不同的），這裏有來自遊戲網站的PHP論壇的一些信息編號：
，這是由COM考慮作爲一個很好的經驗。但這是非常主觀的。
網頁設計大師Vincent Flanders表明，超過4秒的任何內容對於加載網頁來說太長。我認爲這是一個很好的經驗法則。
就緩存或其他性能優化而言，我會建議您執行一些性能測試。市場上有許多性能測試工具包。測試將顯示問題所在的地方。將緩存邏輯添加到已經表現良好的事物中沒有任何意義。另一方面，性能問題可能發生在您可能不期望的地方，涉及您可能沒有考慮過緩存的數據。
我在性能測試中也發現的一點是，它可以在代碼中發現死鎖發生的地方，或者簡單的數據庫優化可以幫助的地方。也許向表中添加索引會加速頁面，而不是添加一堆緩存邏輯。
我會保持簡單，並且只在需要時重構性能。
另外，還要經常測試和測試。我知道很多人都認爲最後要考慮性能，但如果您至少在開發生命週期中沒有考慮到它，那麼您可以真正將自己編碼到一個角落。
一些研究表明，交互式應用程序必須在250ms內提供反饋，以免使用戶認爲它卡住或操作失敗。儘管Web上的接受程度稍高，並且Web瀏覽器通常會提供新的頁面正在加載的反饋。使用AJAX，您必須注意提供som類型的反饋，因爲瀏覽器不會顯示正在發生的事情。
600毫秒以下是相當可敬的。一定要使用Firefox的Firebug，並且YSlow會擴展以準確查看需要加載的時間。 – 2009-03-20 13:11:04