УрокНастройка 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 справлялся с этим не самым лучшим образом.

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

VK Crossposter

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

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

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

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

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

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

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

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

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

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

Страницы