Pamięć podręczna Magento nie jest inna. Zaczynając od podstaw, opcje pamięci podręcznej można przeglądać, przechodząc do
System-> Zarządzanie pamięcią podręczną
w backend. Możesz zobaczyć różne obszary buforowania, które można włączyć / wyłączyć, takie jak dowolne konfiguracje, layout.xml, bloki, pełne strony i pliki API. Oczywiście idealnym rozwiązaniem jest włączenie wszystkich tych funkcji po uruchomieniu witryny.
Pamięć podręczną można również wyczyścić lub opróżnić z tego miejsca. Naciśnięcie przycisku oznaczonego “Flush Magento Cache”spowoduje opróżnienie wszystkich plików pamięci podręcznej, które pasują do określonego zestawu wbudowanych domyślnych tagów używanych przez Magento. Jest to „bezpieczniejszy” sposób na wyczyszczenie pamięci podręcznej, ponieważ nie usuwa absolutnie wszystkiego. Jeśli korzystasz z dodatkowych typów pamięci podręcznej, kliknięcie “Flush Cache Storage”zapewni wyczyszczenie pamięci podręcznej, ponieważ powoduje wyczyszczenie WSZYSTKIEGO. Pozostałe dwa przyciski widoczne na stronie administratora wyczyszczą javascript i css oraz obrazy katalogu.
Alternatywnym i nieco mniej bezpiecznym sposobem na wyczyszczenie pamięci podręcznej jest przejście do
websiteroot / var / cache
i ręcznie usuwając wszystkie pliki. To samo dotyczy
websiteroot / var / full_page__cache
jeśli masz włączone pełne buforowanie strony.
Pełny bufor strony, dostępny w wersji Enterprise Edition, przyspiesza witrynę 10-krotnie, ale ważne jest, aby wiedzieć o niej trochę, na wypadek, gdybyś zauważył, że buforowana jest zawartość dynamiczna. Ciekawym plikiem do obejrzenia jest
websiteroot / app / code / core / Enterprise / PageCache / etc / cache.xml
Tutaj możesz zobaczyć, co jest buforowane przez FPC, nazwę bloku, nazwę kontenera i czas życia sesji. Jeśli uznasz, że absolutnie konieczna jest edycja lub usunięcie któregokolwiek z tych bloków z pamięci podręcznej, możesz to zrobić, tworząc moduł zależny od modułu PageCache i umieszczając w nim wszelkie modyfikacje.
Znacznik zastępczy informuje FPC, że ten blok jest uważany za dynamiczny. Po załadowaniu strony, jeśli blok nie jest jeszcze w pamięci podręcznej, ta wartość identyfikatora w znacznikach zastępczych jest wyszukiwana w pamięci podręcznej, a jeśli nie istnieje, wówczas ten blok jest wywoływany i generowany, a identyfikator jest dodawany do pamięć podręczna.
Funkcję kompilacji Magento można znaleźć pod
System> Narzędzia> Kompilacja
Jeśli uruchamiasz nową instalację, prawdopodobnie pojawi się komunikat systemowy, że oba includes and includes/src/katalogi muszą mieć możliwość zapisu. Gdy to zrobisz, możemy nacisnąć przycisk „Uruchom proces kompilacji” i po prostu gotowe, rdzeń Magento korzysta z kompilacji.
Kiedy Magento kompiluje swój kod źródłowy, framework robi kilka rzeczy. Być albo wywołane przez administratora lub shell, see shell/compiler.phpwszystkie kompilacji odbywa się za pomocą jednej klasy: Mage_Compiler_Model_Process. W tej klasie znajdziesz następujący fragment, który jest w rzeczywistości widokiem z lotu ptaka na cały proces.
/**
* Run compilation process
*
* @return Mage_Compiler_Model_Process
*/
public function run()
{
$this->_collectFiles();
$this->_compileFiles();
$this->registerIncludePath();
return $this;
}
Rozpoczęty $this->_collectFiles();rozmową Magento kopiuje wszystkie pliki PHP z obu
aplikacja / kod
i katalogi lib do
/ obejmuje / src
informator. Jak widać na poniższym fragmencie: podczas tego procesu Magento rekurencyjnie iteruje wszystkie pliki i katalogi. Te ścieżki są ostatecznie używane jako nazwa pliku. Gdy proces rekurencyjny trafi do pliku, sprawdzi, czy nie ma rozszerzenia PHP, a gdy zostanie znaleziony, plik zostanie skopiowany do katalogu kompilatora. Inne typy plików pozostają nietknięte.
Na przykład: ścieżka dla klasy Mage_Catalog_Model_Category była
app / code / core / Mage / Catalog / Model / Category.php
ale z włączoną kompilacją stał się teraz
zawiera / src / Mage_Catalog_Model_Category.php
/**
* Copy files from all include directories to one.
* Lib files and controllers files will be copied as is
*
* @return Mage_Compiler_Model_Process
*/
protected function _collectFiles()
{
$paths = $this->_getIncludePaths();
$paths = array_reverse($paths);
$destDir= $this->_includeDir;
$libDir = Mage::getBaseDir('lib');
$this->_mkdir($destDir);
foreach ($paths as $path) {
$this->_controllerFolders = array();
$this->_copy($path, $destDir); // this one will run recursively through all directories
$this->_copyControllers($path);
if ($path == $libDir) {
$this->_copyAll($libDir, $destDir);
}
}
$destDir.= DS.'Data';
$this->_mkdir($destDir);
$this->_copyZendLocaleData($destDir);
return $this;
}
Kontrolery otrzymują inne leczenie. Wszystkie katalogi kontrolera są kopiowane
zawiera / src /
ale są przechowywane w katalogu, który ma nazwę pokrewnej przestrzeni nazw, pomyśl: Mage, Enterprise lub własną podaną przestrzeń nazw.
W tych katalogach przestrzeni nazw kontrolery są przechowywane dla każdego modułu, a struktura katalogu kontrolera pozostaje nietknięta. To samo dotyczy nazwy pliku, to tylko dokładna kopia. Całą tę logikę można znaleźć w następującej metodzie$this->_copyControllers($path);
Ten drugi poziom kompilacji zbiera wszystkie zakresy i odpowiednie listy klas od administratora. Wszystkie te zakresy są przetwarzane przez pobranie zawartości powiązanych plików klas i zapisanie ich w jednym pliku nazwanym na podstawie podanego zakresu.
/**
* Compile classes code to files
*
* @return Mage_Compiler_Model_Process
*/
protected function _compileFiles()
{
$classesInfo = $this->getCompileClassList();
foreach ($classesInfo as $code => $classes) {
$classesSorce = $this->_getClassesSourceCode($classes, $code);
file_put_contents($this->_includeDir.DS.Varien_Autoload::SCOPE_FILE_PREFIX.$code.'.php', $classesSorce);
}
return $this;
}
Domyślnie Magento tworzy cztery różne pliki zakresu:
__default.php, __catalog.php, __checkout.php i __cms.php
Podczas procesu budowania tych plików zakresu Magento automatycznie analizuje wszystkie rozszerzenia klas i interfejsy, które są używane przez klasy znajdujące się na liście zakresów.
Po zainstalowaniu i skompilowaniu wszystkich plików Magento jest gotowy do włączenia funkcji kompilacji do użycia.
Na koniec dostosowywana jest konfiguracja związana z kompilacją. Ten plik można znaleźć w includes/config.phpi zawiera następujące dwie stałe. Po włączeniu kompilacji wiersz dotyczący COMPILER_INCLUDE_PATH nie jest komentowany i dlatego jest gotowy do działania.
> #define('COMPILER_INCLUDE_PATH', dirname(__FILE__).DIRECTORY_SEPARATOR.'src');
> #define('COMPILER_COLLECT_PATH', dirname(__FILE__).DIRECTORY_SEPARATOR.'stat');
Kod odpowiedzialny za dostosowanie pliku konfiguracyjnego można znaleźć w metodzie registerIncludePath metody Mage_Compiler_Model_Process class.
Podczas ładowania początkowego plik konfiguracyjny kompilacji jest zawarty w pliku index.php file (around line 44). Dzięki temu stałe include_path są dostępne w całym frameworku. Ścieżkę zbierania można włączyć tylko ręcznie, aby uzyskać więcej informacji statystycznych dotyczących wykorzystania skompilowanych plików. To nie powinno być włączone na żywo.
/**
* Compilation includes configuration file
*/
$compilerConfig = 'includes/config.php';
if (file_exists($compilerConfig)) {
include $compilerConfig;
}
Od tego momentu Magento sprawdzi, czy tryb kompilacji jest włączony za pomocą następującej instrukcji. Przeglądając bazę kodu (używając „grep”) zauważysz, że większość tej logiki można znaleźć w lib/Varien/Autoload.phppliku.
if (defined('COMPILER_COLLECT_PATH')) {
// do stuff
}
Innym miejscem do poszukiwania jest Mage_Core_Controller_Varien_Action. W tej klasie znajdziesz preDispatch()metodę, która jest wyzwalana dla każdej metody akcji kontrolera, zanim metoda zostanie faktycznie wywołana. W tej części źródłowej klasy autoloadera Magento wzywa się Varien_Autoload do załadowania określonego pliku zakresu kompilacji.
Mage::dispatchEvent('controller_action_predispatch', array('controller_action'=>$this));
Mage::dispatchEvent(
'controller_action_predispatch_'.$this->getRequest()->getRouteName(),
array('controller_action'=>$this)
);
Varien_Autoload::registerScope($this->getRequest()->getRouteName()); // right here
Mage::dispatchEvent(
'controller_action_predispatch_'.$this->getFullActionName(),
array('controller_action'=>$this)
);
Podczas pracy w trybie kompilacji Magento ma tylko jedną ścieżkę dołączania, includes/src/katalog, więc każdy plik znajduje się bezpośrednio przy pierwszej próbie. Dzięki znacznej liczbie plików, które posiada Magento, oszczędza to sporo czasu. Poniższy fragment pochodzi z
app / Mage.php
if (defined('COMPILER_INCLUDE_PATH')) {
$appPath = COMPILER_INCLUDE_PATH;
set_include_path($appPath . PS . Mage::registry('original_include_path'));
include_once "Mage_Core_functions.php";
include_once "Varien_Autoload.php";
} else {
/**
* Set include path
*/
$paths[] = BP . DS . 'app' . DS . 'code' . DS . 'local';
$paths[] = BP . DS . 'app' . DS . 'code' . DS . 'community';
$paths[] = BP . DS . 'app' . DS . 'code' . DS . 'core';
$paths[] = BP . DS . 'lib';
$appPath = implode(PS, $paths);
set_include_path($appPath . PS . Mage::registry('original_include_path'));
include_once "Mage/Core/functions.php";
include_once "Varien/Autoload.php";
}
Gdy PHP zawiera plik, zawartość jest kompilowana do opcode. Jest to proces, który należy wykonać za każdym razem, gdy plik jest dołączany. Aby jeszcze bardziej poprawić wydajność swojego sklepu, możesz zainstalować APC na swoim serwerze. APC buforuje zakodowane wersje plików, udostępniając je dla kolejnych żądań. Tak więc na następne żądanie: plik zostanie odczytany z pamięci podręcznej APC, zamiast ponownie przejść ten sam proces i obniżyć wydajność.