БлогКэш страниц. Снижение нагрузки на сервер с помощью Memcache Storage Page Cache

Сегодня я хотел бы рассказать ещё об одном моём модуле, который позволяет серьёзно снизить нагрузку на сервер. Но перед тем, как я расскажу про сам модуль, мне хотелось бы начать с небольшого рассказа про работу кэша страниц для анонимов.

Page Cache в Drupal 7

Эту часть я разобью на 3 небольших ступени, каждую из которых необходимо полностью понимать.

Ступень первая. Ядро Друпала содержит механизм кэширования отображаемых html страниц для анонимных пользователей. Вполне разумно - какой смысл создавать каждый раз одну и ту же страницу, если можно сгенерировать её для одного анонима, а остальным отдавать уже готовый результат. В таком случае Друпал не будет каждый раз вызывать функцию для генерации и рендера страницы, а лишь заберёт страницу из кэша и сразу отдаст её пользователю.

УрокДебаг запросов к базе данных

В Drupal 7 все sql запросы собираются с помощью PDO конструкций, в которые передаются разнообразные параметры для построения запроса. И нередко приходится сталкиваться с ситуацией, когда хочется посмотреть результирующий sql запрос, сформированный в результате запуска PDO конструкции на исполнение. У нас есть как минимум три способа это сделать, каждый из них имеет свои плюсы и минусы. Давайте рассмотрим каждый из них.

Вывод запроса на экран средствами ядра

Предположим, у нас есть такой запрос:

$query = db_select('node', 'n');
$query->fields('n', array('nid', 'title'));
$query->condition('n.status', NODE_PUBLISHED);
$query->orderBy('n.nid');
$result = $query->execute();

Для того, чтобы вывести его на экран, достаточно у PDO объекта $query вызвать метод __toString():

drupal_set_message($query->__toString());

БлогПеренос кэшированых данных в оперативную память. Memcache Storage.

Memcache Storage

Не так давно я писал про изменение места хранения кэша. В этой статье основной пример основывался на использовании модуля Memcache, который позволяет перенести хранимый кэш из базы данных в оперативную память. На момент написания статьи я достаточно давно и активно им пользовался, и в целом, был доволен результатом. Однако было три основных и достаточно неприятных момента, с которыми я постоянно сталкивался:

Инвалидация кэша

Основная проблема кроется в плохой обработке временного кэша. При хранении в базе данных такие данные помечались флагом -1 (CACHE_TEMPORARY) и обрабатываются обычными sql запросами. Однако мемкэш не предполагает сохранения кэша с отрицательным ключём. Он умеет хранить данные либо вечно (пока оперативная память не будет очищена, или данные не будут удалены явным образом), либо какое-то определённое время. Данные с временным сроком истечения кэша приходилось обрабатывать отдельно, и модуль Memcache справлялся с этим не самым лучшим образом.

БлогVkontakte CrossPoster 2. Воскрешение.

VK Crossposter

Сегодня произошла очередное возвращение кросспостинга во VK. Инициатива по допиливанию модуля была поднята разработчиком по имени Дмитрий, за что ему большое человеческое спасибо. Однако давайте обо всём по порядку.

Разработчики Вконтакта так и не дали возможность публиковать веб-сайтам сообщения на стену. Но теперь мы будем маскироваться под Desktop приложение, чтобы всё работало как хочется. Из-за этого при получении токена из вконтакте нам придётся столкнуться с одним маленьким костылём. Однако, согласитесь - это намного лучше, чем неработающий кросспостинг :)

УрокСистема кэширования Drupal 7. Часть третья: ускоряемся за счёт изменения места хранения кэша.

По умолчанию Друпал хранит весь кэш в базе данных (см. сегменты кэша). Однако для высоконагруженного проекта чем меньше вы нагружаете базу данных - тем быстрее будет отдаваться контент и, соответственно, вы минимизуете риск образования бутылочного горлышка на вашем сайте. Сегодня я хотел бы рассказать каким образом можно вынести хранение кэша в другое место, а так же спалить достаточно простой способ тюнинга сайта, чтобы он смог выдержать большую нагрузку для анонимных посетителей.

Меняем хранилище кэша

Чтобы несколько разгрузить базу данных, хорошей практикой считается вынос кэша вне базы данных. Например, в оперативную память. Логика здесь простая - зачем нам обращаться к жёсткому диску, если можно получить данные быстрее из оперативной памяти, которая, собственно, для этого и предназначена? Одной из библиотек, позволяющих это реализовать, является Memcache Storage. На его примере я и объясню как это работает.

УрокСистема кэширования Drupal 7. Часть вторая: программное управление кэшем.

Сегодня наконец дошли руки написать продолжение серии статей о кэшировании. В первой части были рассмотрены сегменты кэша, которые находятся в ядре седьмого Друпала. Сегодня же мы поговорим о том, как работать с кэшем программно. Для примера создадим модуль, который предоставляет свой сегмент кэша и управление им.

Шаг первый. Создание нового сегмента кэша.

Назовём наш модуль, например, Example cache. Для создания своего сегмента кэша практически всегда используется клон стандартной таблицы {cache}, поэтому и мы не будем исключением. В example_cache.install имплементируем hook_schema(), чтобы добавить свою таблицу:

БлогМодуль по добавлению мета-тегов. Path Metatags.

Не так давно мной был написал модуль, позволяющий удобно добавлять мета-теги Path Metatags. Алгоритм его работы похож на работу Path Breadcrumbs (по шагам):

  • Указание пути, на котором будут отображаться мета-теги
  • Привязка к переменным из пути контекста
  • Указание правил показа мета-тегов для пути
  • Выбор мета-тегов и информации для отображения

Подробно о добавлении мета-тегов я расписывать не буду, т.к. всё то же самое можно почитать в статье о модуле хлебных крошек. Однако последняя форма с самим добавлением мета-тегов, безусловно, другая:

БлогУскоряем бутстрап или борьба с неправильным удалением модулей

На одном из проектов я столкнулся с необходимостью оптимизации сайта. Проанализировав серверную часть сайта я заметил, что бутстрап на каждую загрузку страницы съедал ~350 милисекунд. Довольно много, учитывая, что это лишь загрузка необходимых компонентов. Потратив ещё некоторое время на поиск проблемы я выяснил, что каждый раз при загрузке страницы Друпал сканировал все мои папки с темами и модулями заново. Это и являлось основой задержкой в бутстрапе, т.к. на это сканирование тратилось около 280 милисекунд (102 модуля и 2 темы). И это при том, что проект стоит на отдельном сервере, который полностью заточен под Drupal 7.

После осознания проблемы у меня возникло два вполне логичных вопроса:
1. Какого @#$ так долго?
2. Почему это нельзя было закэшировать?

Как выяснилось - Друпал это уже кэширует. И всё обычно хорошо и правильно работает ... пока разработчик не начинает удалять модули неправильно. Некоторые разработчики удаляют модули деревянным способом: физическим удалением модуля с сервера. И вроде бы модуль перестаёт работать, и вроде бы результат достигнут... Однако что при этом происходит в Друпале?

Страницы