Мы уже разговаривали о кешировании и парсинге здесь и здесь. И вот еще небольшая порция информации для размышления.
Что мы имеем? Небольшой сайт-визитку с каталогом. На главную выводится помимо парочки менюшек еще и главный источник проблем в области производительности — галерея товаров с использованием пакета Gallery.
В принципе у нас главная не меняется, потому у нас стоит задача максимально закешировать документ, чтобы вообще летало.
Посмотрим какой производительности можно добиться, применяя кеширование.
Сразу вкратце обрисую схему работы документа: в шаблоне только один исполняющий сниппет, который подгружает PHP-файл и там уже происходит основная работа. То есть по идее, если мы сделаем этот сниппет кешируемый, у нас должно получиться максимальное кеширование. Посмотрим.
Вариант 1. Документ не кушируемый вообще. Генерация страницы 760-900 мсек.
Вариант 2. Документ кешируемый, сниппет не кешируемый. Генерация 630-700 мсек.
Вариант 3. Сниппет полностью кешируемый. Генерация 217-275 мсек.
Итак, у нас полное кеширование корневого сниппета. А генерация 200+ мсек. В чем проблема? Проблема в том, что внутри этого сниппета могут встречаться другие некешируемые элементы. Но даже если эти элементы кешируемые, в кеше документа все равно не будет сплошного HTML-кода, а будет массив кешируемых элементов с их значениями, и все равно при каждой загрузке страницы MODX-парсер будет пробегаться по этим элементам и заменять их на их значения. Вот часть кеша этой страницы:
'[[$webim.output]]' => '<div style="margin: 0 0 0 16px;"> <!-- webim button --><a href="/webim/client.php?locale=ru" target="_blank" onclick="if(navigator.userAgent.toLowerCase().indexOf(\'opera\') != -1 && window.event.preventDefault) window.event.preventDefault();this.newWindow = window.open(\'/webim/client.php?locale=ru&url=\'+escape(document.location.href)+ \'&referrer=\'+escape(document.referrer), \'webim\', \'toolbar=0,scrollbars=0,location=0,status=1,menubar=0,width=640,height=480,resizable =1\');this.newWindow.focus();this.newWindow.opener=window;return false;"> <img src="/webim/button.php?i=webim&lang=ru" border="0" width="163" height="61" alt=""/> </a><!-- / webim button --> </div>', '[[~9]]' => 'chugunnie_radiatory.html',
Может не очень видно, но это ассоциативный массив с двумя ключами: '[[$webim.output]]' и '[[~9]]'.
То есть как мы не старались, у нас все равно документ закеширован не идеально.
Но нам есть еще что сказать…
Вариант 4. Парсим полученный сниппетом контент.
Итак, прежде чем в сниппете выполнить return $output, выполняем следующее: дописываем перед return парсинг имеющегося контента.
$maxIterations= intval($modx->getOption('parser_max_iterations', null, 10)); $modx->parser->processElementTags('', $output, true, false, '[[', ']]', array(), $maxIterations); $modx->parser->processElementTags('', $output, true, true, '[[', ']]', array(), $maxIterations);
Таким образом мы уже на уровне сниппета обработаем все MODX-элементы в полученном контенте, и в кеш страницы запишется в качестве значения нашего сниппета чисто конечный HTML-код.
И что мы имеем на выходе? Генерация страницы 84-100 мсек. Много или мало? Для сравнения если прописать в index.php exit сразу перед выполнением $modx->handleRequest();, то есть MODX проинициализируется, но не начнет еще обрабатывать запрос и генерить страницу, это время составит 60-70 мсек.
Но даже это еще не все. Я уже писал про свои шаблоны, в которых будет выполняться чистый php-код. То, как MODX работает сейчас, хочу я или нет, но хотя бы один сниппет MODX-парсер вынужден обработать, который прописан в шаблоне. Выполнение же php-кода на уровне шаблона позволит получать из пользовательского кеша полный HTML-код страницы, и отдавать этот код сразу браузеру, не дожидаясь работы MODX-парсера. Скорее всего даже здесь это добавит еще как минимум 10 мсек. экономии.
Так что работа в этом направлении продолжается.