自動重建緩存

我運行的Symfony 1.4項目的數據量非常大。主頁面和類別頁面正在使用尋呼機，它們需要知道有多少行可用。我將包含連接的查詢傳遞給尋呼機，導致這些頁面上的加載時間爲1分鐘。自動重建緩存

我爲各自的操作配置了cache.yml。但我認爲解決方法是不充分的，這裏是我的假設：

Symfony在用戶創建的單個請求中重建緩存。讓我們稱這個用戶爲「緩存受害者」來簡化事情。

在我們的案例中，數據需要更新 - 10分鐘的使用壽命就足夠了。顯然，如果沒有用戶願意成爲「緩存受害者」並因此取消請求，緩存將不會被重建。這些假設是否正確？

所以，我想出了這個想法： Symfony在重建緩存後應該僞造http請求。一旦緩存重建完成，新的緩存條目應寫入臨時文件/目錄，並應與先前的緩存條目交換。

這可能嗎？

在我看來，這與雙緩衝的概念相似。

如果多人遊戲中有一個單獨的「GPU受害者」看到屏幕逐行建立，那麼這不是愚蠢嗎？（這是一種片面的比較，我知道...;））

編輯

沒有「緩存受害者」 - 每10分鐘刷新頁面需要爲每個用戶1分鐘。

2011-07-06 fishbone

坦率地說，我想先看看爲什麼計數傳呼機行（？如果我理解正確的）需要1分鐘去完成。無論哪種方式，要解決的顯而易見的問題是帶有陳舊緩存的加載時間。其次，取消請求的用戶通常不會阻止網絡服務器完成運行請求（除非超時或達到另一限制）。 – Gerry

好的，那麼「處理請求」將被取消。由於大量的數據和連接需要1分鐘。尋呼機查詢本身非常簡單。尋呼機需要知道條目的數量，因爲它會計算可用的頁數。 – fishbone

我建議你應該先處理這個問題，但是我沒有看到關於爲什麼填充尋呼機需要很長時間的明智解釋。我相信你可以優化，但不能進一步評論，而不知道具體細節。 – Gerry

我認爲你的問題是由於一些缺失或錯誤的索引。對於一個大型足球網站（即每天2M頁）我有一個sf1.4項目，即使我們的數據庫最近有超過1M的行，尋呼機也不會太慢。看看你的查詢與EXPLAIN，並檢查它去哪裏壞...

2011-10-30 12:53:47 dlondero

我試着用EXPLAIN和優化索引。我們升級了硬件，使事情變得更好。但是，你沒有回答我的問題。我問是否可以使用緩存交換的概念。爲什麼用戶在構建新的緩存條目時需要等待？ - 舊的緩存條目仍然可用。 – fishbone

我看不到這一點。是的，緩存交換是可能的，但該解決方案僅適用於一些非常關鍵的場景。我認爲你可以通過另一種方式解決你的數據庫問題。 – dlondero

對不起necromancing（有沒有徽章？）。通過配置cache.yml，您只需緩存您的應用程序的視圖層（即css，js和html）以便無需參數。導航尋呼機顯然在GET請求上有一個？page = X。

從symfony的1.4 config.yml文檔摘自：

與在查詢字符串GET參數傳入的請求或與提交POST，PUT或DELETE方法永遠不會由symfony中被高速緩存，而不管組態。 http://www.symfony-project.org/reference/1_4/en/09-Cache

2012-08-02 04:35:34 JavierIEH

回答