УрокОтдаём кэш анонимов без поднятия бэкэнда. Drupal 7 + nginx + memcached.

Помните статью о снижении нагрузки с помощью Memcache Storage? Там Drupal отдавал анонимам кэш на второй фазе бустрапа, что существенно снижало нагрузку на сайт, особенно его посещали преимущественно анонимные пользователи. Там отдача страницы происходила за 50-70мс. Однако я решил этим не ограничиваться, и отдавать кэш вообще без поднятия бэкэнда (на большинстве хостингов это apache). Таким образом мало того, что отдача страницы происходит в десятки раз быстрее, так ещё и не расходуется память на новые процессы апача (или любого другого бэкэнда).

Чтобы понимать, что происходило раньше при отдаче страниц анонимам (по материалам этой статьи), я накидал небольшую схему:

БлогНовый Cache Expiration - полная свобода в выборе правил для сброса кэша страниц

В данной статье я хотел бы поговорить о сбросе кэша страниц. По сути, эта статья вытекает из материала про Memcache Storage Page Cache и снижение нагрузки на сервер. Однако как верно заметил товарищ @quicksketch, в моём Memcache Storage PC не было ничего, что привязывало бы этот модуль конкретно к мемкэшу. После небольшого обсуждения было решено смержить все его фичи в Cache Expiration, который на тот момент включал в себя крайне много хардкода. Потратив приличное время на объединение Memcache Storage PC и Cache Expiration, а потом и на написание новых фич (и в итоге переписав всё с нуля) была создана вторая ветка этого великолепного модуля - Cache Expiration 7.x-2.x.

Урок84 настройки Друпала, о которых вы могли не знать

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

Я потратил немалое количество времени и нашёл все переменные, которые невозможно задать с помощью UI. В этот список вошли как некоторые настройки из settings.php, так и абсолютно недокументированные. Некоторые переменные я сам узнал впервые, и был приятно удивлён этим открытием. Переменные, которые я счёл полезным к изучению, я выделил зелёным цветом. Переменные, которые я считаю, что знать обязательно - красным. Остальные просто для ознакомления, чтобы просто держать в голове уровень возможностей системы.

УрокНастройка Drush. Алиасы и дополнительная конфигурация.

За хранение алисов для drush отвечает файл drushrc.php. Он может находиться в следующих местах:

1. В директории с конфигурацией сайта (например, sites/{default|example.com}/drushrc.php).
2. В директории sites/all/drush (sites/all/drush/drushrc.php).
3. В любой директории, указанной с помощью опции --config (-c).
4. В пользовательской директории .drush (например, ~/.drushrc.php).
5. В конфигационной папке операционной системы (например, /etc/drush/drushrc.php).
6. В директории, в которую был установлен drush.

Этот файл можно взять тут.

Если drush обнаружил этот файл в нескольких директориях, то настройки из них будут объеденены путём мержа конфигурационных массивов. Если же ваш конфиг рассчитан на определённую версию drush, то вы можете переименовать этот файл в drush[НОМЕР-ВЕРСИИ]rc.php. Например, для пятого драша этот файл будет называться drush5rc.php.

Давайте рассмотрим несколько примеров из его конфигурации, которые могут облегчить жизнь при разработке.

УрокУскоряем работу с memcached. Сокеты, PECL Memcached, настройки.

В рамках подробного изучения внутренней кухни мемкэша я обнаружил несколько нюансов, которые позволяют существенно увеличить количество запросов в секунду (request per second) к данным, хранящимся в мемкэше, а также повысить эффективность использования оперативной памяти. По итогам моих экспериментов я выделил 4 основных пункта, каждый из которых существенно влияет на производительность:

1. Доступ к демону осуществляется быстрее через сокеты (что, в принципе, и не удивительно).
2. Библиотика PECL Memcached работает быстрее, чем PECL Memcache (а вот это для меня оказалось сюрпризом).
3. Настройки для библиотек по-умолчанию использовать нельзя, надо конфигурировать самостоятельно.
4. Настройки для демона memcached также необходимо подстраивать под сервер и используемую среду, дефолтные никуда не годятся.

Давайте теперь рассмотрим эти пункты более подробно.

БлогКэш страниц. Снижение нагрузки на сервер с помощью 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 справлялся с этим не самым лучшим образом.

Страницы