655
magento -- 給Magento提速之緩存上的探索
依然在為Magento提速做努力，除了自帶的緩存和編譯，之前的所作的很多努力都是從減少JS，Css,圖片等載入時間入手，而對頁麵載入耗時最早有時也是最大的一部分--獲取頁麵數據沒有做太多處理，以gap.cn為例，用firebug看下各個請求的耗時（數據受多方麵因素影響，僅供參考）：
可以看到js和css的載入時間一般是以幾十毫秒來計算的，而載入的第一步頁麵數據卻要花掉將近一秒，在用各種方法縮短js，css和圖片的載入時間後，想要讓Magento跑的更快，就得想辦法從縮短這“781ms”處下手。
因為Magento複雜的代碼架構和EAV模式的數據庫，導致每次頁麵載入都要讀取大量的php文件和大量的數據表，自帶的緩存將一些常用的數據緩存到了文件裏，而不需要每次都去讀取數據庫，這提醒了我們一種思路，就是將頁麵上常用的數據都緩存起來，減少讀取php文件和數據庫的需要。不記得在哪裏看到過一篇文章提到，Magento自帶的緩存方案相當保守，緩存的數據很少，頁麵載入時依然要從數據庫讀取大量的數據。我們所要做的就是改進緩存的方案，將更多數據緩存到文件中去。
我對緩存的研究不是很深，個人理解大概分兩種，一種是整頁緩存，一種是局部緩存，以我測試過的兩個緩存插件為例闡述下觀點。
第一個插件是一個整頁緩存的插件--Performance Booster，官網上的地址是https://www.magentocommerce.com/magento-connect/AITOC,+Inc./extension/4865/performance_booster，這個插件開啟後，會在前台每訪問一個頁麵後就生成一個靜態html，下次再訪問相同頁麵時會直接讀取靜態文件的內容，速度提升相當明顯，能將第一步html的載入時間從幾百毫秒直接提升到幾十毫秒。這個插件的代碼裏監聽了一大堆事件，用來刷新緩存，比如後台修改產品信息後保持的時候會刷新對應的緩存。
按說這個插件已經將可能需要刷新緩存的狀況都考慮到了，但我在使用的時候卻遇到了麻煩。因為Magento是個高度開放的係統，可以安裝各種各樣的第三方插件，也可以自己寫一些新模塊進去。插件不可能考慮到除了係統自帶模塊以外需要刷新緩存的情況，這就導致了頁麵某些部分在後台數據已經改變的情況下前台沒有刷新或者有一些功能塊直接出現異常無法使用。而我所經手的項目大多都裝有不少插件，以及自己所做的修改，所以很難有機會用上這個插件了。
第二個插件是一個免費插件--CatalogCache，官網上的地址是https://www.magentocommerce.com/magento-connect/netresearch/extension/2138/catalogcache，這個插件功能很簡單，就是緩存了Catalog/Product_View和Catalog/Product_List這兩個block的數據，對頁麵上來說，也就是緩存了產品列表頁的產品數據和產品詳細頁的產品數據，隻緩存局部，而不是整個頁麵。經測試，在產品數比較多的列表頁和產品頁，開啟這個插件後能帶來大概100ms--到200ms不等的速度提升。因為隻緩存了兩個block，所以插件也隻對列表頁和產品頁起效果。
這個插件功能簡單，針對性強，所以也不用擔心會對列表頁和產品頁以外的東西造成影響，經過一段時間測試沒問題後已經用在了正式的項目上。當然推薦這個插件並不是這篇文章的主要目的，而是這個插件讓我覺得用同樣的方式給各種常用block寫緩存是種安全而又實用的方式，雖然效果上肯定比不上直接讀靜態文件來得快，但因為是自己一塊塊寫的，不需要擔心整頁緩存時會有哪一塊遺漏了沒有照顧到。也就是說，不管你添加了多少第三方插件，或者自己寫了多少功能，依然可以用這種方式來做優化，自己選擇性的給局部做緩存。
得出我自己的觀點，整頁緩存的適應性不夠好，無法應對各種不同的項目情況，如果你的Magento站隻是在默認功能上套了個模板，可以嚐試下第一個插件，如果項目有不少第三方插件，甚至做了不少二次開發，那麼就放棄整頁緩存方案。所以局部緩存才是我認為最適合Magento的方案，雖然效果比不上整頁緩存，但勝在靈活，安全，適應性強。
個人膚淺的觀點，歡迎拍磚！
最後更新：2017-04-02 06:51:30