今天我處理了一個任務，在負載較重的情況下將模塊的配置加載到正在運行的Magento站點。我複製了新模塊的config.xml文件和一切以解決一些問題。能夠在不清除緩存的情況下重新加載Magento站點配置中的更改
我們的Magento使用memcached緩存後端運行。
爲了讓一個模塊正常運行，我必須徹底清除緩存，並且對網站的性能有影響，我們有500個concurent用戶。所以我正在尋找解決方案如何在不清除緩存的情況下部署配置更改。
有沒有？
感謝您的任何想法和想法。
Jaro。
這裏是方法更新的配置高速緩存而不是清除它，因此避免了競賽條件。
您不必清除整個緩存以加載模塊的配置。您可以使用Flush Magento Cache *選件安裝模塊。最終，您需要清除緩存以查看您的前端更改（如果有）。要最大限度地降低性能影響，最好的辦法是在非高峯或低使用率的時候清除它。
*編輯 - 感謝Fiasco Labs
** Flush Cache Storage **是Flush Magento Cache **的核心選項，如此處所述... http://stackoverflow.com/questions/5955365/what-is-the-difference-between -flush-magento-cache-and-flush-cache-storage -i清除緩存僅影響Magento，清除緩存存儲也會擦除服務器上的其他php應用程序。所以他們都沖洗緩存，只有一個更徹底。 – 2012-02-07 22:10:47
我認爲必須有另一種方式來安裝一個模塊而不清除整個緩存。如果需要，我會優先考慮檢查所有模塊並強制安裝過程的任何方法。最後，如果你是一個作者，那麼知道它會做什麼:) – Jaro 2012-02-10 13:37:27
你將永遠有刷新緩存安裝模塊或更改其配置的時候。這對於強制重新讀取配置，清空不兼容的操作碼以及強制Magento重新讀取應用程序代碼和模板以適應您剛纔所做的更改而言非常必要。
是的，它對您的網站的性能有一個短暫的影響，但如果您沒有，它可能會導致一些非常有趣的問題。
我曾經有過在Admin中使用按鈕不夠用的情況，對於模塊安裝來說，最好將系統置於維護模式，確保所有管理員會話都已註銷，檢查每個人都沒有出來，然後手動刪除var/cache/mage--？文件夾。然後重新登錄一個管理會話，讓它運行直到您看到管理會話已啓動，然後重新登錄，然後返回到管理員以開始檢查站點以獲取新安裝的模塊的全部功能。
這對於緩存刷新足夠的簡單配置更改當然是矯枉過正的。
我會說這是過度的方法:-) – Jaro 2012-02-10 13:35:26
是的，它是。我們如何像編譯的程序一樣快速地創建腳本語言程序？我們緩存東西而不是創建目標文件並將它們鏈接到可執行文件中。 Wayback的時候，這是與解釋帕斯卡試驗。當源代碼發生變化時，所有這些p代碼文件都不需要刷新。同樣的事情適用於用PHP完成的任何緩存。改變垃圾，得到刷新緩存。解決這個問題的唯一方法是清除特定的緩存標記，並希望能夠找到發生了變化的內容。在上面，可能只是清除CONFIG會起作用。 – 2012-02-12 07:53:03
我試過這個有限的緩存標記刪除，只有每隔一段時間都有一些東西卡在APC中。最後，通過直接文件刪除來清除問題簡直沒那麼麻煩，因爲這似乎迫使APC完全刷新而不會錯過節拍，並且可以節省客戶在前端看到奇怪的混亂垃圾，整個管理員都會消失在後端。高速緩存在繁忙的站點上快速重建。 – 2012-02-12 07:56:55
它把系統維護模式可能是最好的做法，確保所有管理會話註銷，檢查每個人的出來，然後手動刪除VAR /緩存/ mage--？文件夾。然後重新登錄一個管理會話，讓它運行直到您看到管理會話已啓動，然後重新登錄，然後返回到管理員以開始檢查站點以獲取新安裝的模塊的全部功能。
它看起來不錯！謝謝，我會試試它並讓你知道。 – Jaro 2012-05-17 09:08:25
當Magento緩存新資源適配器的名稱（Magento_Db_Adapter_Pdo_Mysql）並在'app \ code \ core \ Mage \ Core \中引發致命錯誤時，它升級到1.8.0.0並降級到1.7.0.2（使用Git分支）在'_newConnection（）'上的'Model \ Resource.php'上有一行'$ connection = new $ className（$ config）;'。清除緩存沒有幫助。我不知道爲什麼它會以這種方式運行，但我讓我發瘋。從Gist運行代碼後，我的實例再次正常運行，謝謝！ – Wirone 2013-09-30 15:08:16