magento開源全頁緩存

Question

我最近和一位開發人員說過，即使使用默認安裝，也沒有magento CE整頁緩存能夠完美運行。

我對此的體驗是一樣的。

如果您使用aoe_static的awesome模塊和phoenix的整頁緩存與清漆模塊，您將得到關閉。

使用aoe_static模塊緩存是基於每個Action完成的，這對我來說似乎是明智的。 打孔是通過布局xml應用的占位符和通過ajax調用請求的動態塊完成的，不會被緩存。 Cookie也是通過此調用設置的。 他提供了一個默認的vcl，它適用於清漆2（我從未檢查過），可以很容易地更換為清漆3。

phoenix模塊很好地處理了緩存失效。 您可以在模塊的控制文件夾中看到這些方法。 這樣可以在產品或類別更改時處理緩存失效，並使產品頁面和類別頁面無效。 但是，分層導航生成的url可能會被緩存（取決於你的vcl）。 這些都沒有失效，所以要小心。

在我在生產網站上使用它們之前，我真的想知道這些模塊是否存在任何其他問題。 如果有人能指出我的問題，我會很樂意嘗試發布一個解決方案。

但對於分層導航網址，需要一個模型來記錄生成的網址與類別ID。 我想有一個2列模型 - 網址和類別 - 很簡單，然后緩存失效需要檢查模型並使額外的網址無效。 這應該在主類別url完成的同時完成。 聽起來不太糟糕。 如果有人得到我非常簡短的解釋，請在我浪費時間之前告知我是否遺漏了什么。

我寧願創建一個開源項目，其中包含一些社區幫助（或者更有經驗的人），至少在默認的1.7安裝中具有（應得的）可靠性聲譽。 我認為最明智的做法是創建一個包含或記錄所有邊緣情況（默認為1.7安裝）的模塊。

有誰知道怎么去做這樣的任務？ 如果有更多的社區支持使用apc或memcached執行此操作，這可能對更廣泛的主機可用性更為明智。 邏輯或開發時間不會有太大變化。

這可以擴展到覆蓋塊的會話緩存，應該記住，但我認為專注於可靠的整頁緩存應該是優先事項。

您還可以檢測vcl中的設備。 這可以添加到想要移動版本的商店https://github.com/varnish/varnish-devicedetect/blob/master/devicedetect.vcl

我已經為這個項目創建了一個電子郵件，所以如果你想參與其中，那就是“magefpc gmail com”。 任何有magento，git和調試經驗的人都會受到歡迎。

謝謝

Answer 1

1問題aoe_static可能包含的內容是，當前擴展程序不會記錄產品，因此后端中有關已查看產品的統計信息不會更新。 這最近作為TODO注釋添加到github中。

清漆和magento緩存的問題是，頁面，塊和清漆的magento緩存部分確實緩存了整個頁面。 所以即使鳳凰解決方案有適當的觀察員並在產品/類別更新時相應地重置清漆，你仍然有magento塊需要重置。 aoe_static嘗試解決這個問題，但它僅適用於頁面上的可見塊。 但是，作為分層導航，magento的其他部分可能會在產品/類別更新內部重置，但不會在清漆中重置。 有2個解決方案。 要么在前端確定magento的每個部分，而不是在產品/類別更新后重置，並對其應用aoe_static解決方案。 這意味着你必須通過ajax加載分層導航。 或者第二個解決方案是，在phoenix擴展中添加更多邏輯以使更多的清漆頁面無效。

我有幾個自定義擴展（顯示產品的頁面）和我構建邏輯，以便每次更新產品/類別時使這些擴展無效。 現在我正致力於搜索，因為這也需要被無效，但復雜的部分是，解決塊和緩存失效邏輯。

總體而言，適當的緩存失效是Web開發中最難的部分之一。

Answer 2

我希望這篇文章是一個社區答案，詳細說明特定句柄的方法，並建議緩存和失效邏輯，如果它還沒有包含在phoenix或aoe_static模塊中。 基本上緩存將由aoe_static模塊中布置的模塊/控制器/動作模式完成，並且Phoenix模塊中存在大多數現有的失效。

所以我們需要決定應該通過ajax呈現哪些塊以及需要添加高速緩存失效的位置。 像gondo說你需要添加更多的失效邏輯來緩存搜索。 我計划從目錄，cms和aw博客頁面開始縮小，這里做了很多，但還需要更多。 如果我們也可以在gondo :)的幫助下添加搜索，那就太棒了。

例如 - 小部件實例可能是一個問題，靜態塊保存也是如此。 只有通過使用core_model_abstract方法_beforeSave（）調度的事件運行總緩存失效，才能輕松解決（就我的快速調查所示）

  Mage::dispatchEvent('model_save_before', array('object'=>$this));

我們需要在使整個緩存失效之前匹配模型的類型。 此模式還可以在緩存失效的其他困難區域中實時節省。 使用instanceof方法很好，但我們需要知道要檢查的模型名稱。 我猜這里的社區參與度很高，因為代碼很容易，但缺少一個模型。

從前端的角度來看，小部件基本相同。 有產品的那個應該加載aoe_static，因為它們經常變化。 但靜態的可以被視為靜態（html）塊。

我們不希望在保存產品時使整個緩存無效，並且無法檢查產品是否已包含在窗口小部件中。 但是aoe_static模塊適用於布局渲染。 小部件需要通過布局xml包含在內，而不是像往常一樣包含在管理系統中。 這些小部件可以添加到呼叫控制器手柄中，並將占位符添加到需要處理的內容中。

完全清漆失效，不時，不是床上用品。 如果它經常發生，或者如果在需要時沒有發生，則整個緩存失效是一個問題。 主要目標應該是捕獲每個失效場景並在管理面板中觸發通知，與保存產品時相同的消息類型：“一個或多個緩存類型無效......”這樣管理員可以做出決定如果他/她想要手動使緩存無效或等待。 並且可以基於這種情況建立一些自動失效邏輯。

還必須創建模型來存儲由分層導航創建的URL，這些應該與類別視圖URL一起失效。

並且考慮到分層導航和失效，我們必須在保存屬性時使整個緩存無效（我認為）。

我們應該能夠將產品評論放在產品頁面上而不需要jj用於seo目的。

這意味着當保存評論模型時，必須使用model_save_before事件檢查它，我們應該使產品頁面網址無效。 這個保存更改了評級，但我建議在ajax調用中獲取此塊。 這對seo來說並不重要。 這適用於產品視圖和列表頁面。

我們還可以緩存和使審核模塊頁面無效，但這對大多數用戶來說並不重要，應該等待。

誰想要標簽塊。 這些不能被ajax加載它會破壞它們的目的。 與此同時，他們現在不值得我們付出努力。

如果你使用附加的會話ID緩存url，它將導致用戶得到我被告知的每個其他會話。 我認為這可以通過基於正則表達式的vcl_fetch中的管道來輕松解決。

這個答案變得混亂，應該很快重新起草。 隨意加2美分!!