cache

УрокОтдаём кэш анонимов без поднятия бэкэнда. 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.

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

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

Page Cache в Drupal 7

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

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

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

Memcache Storage

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

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

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

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

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

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

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

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

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

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

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

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

По опыту начал замечать, что многие разработчики, особенно junior/mid уровня, имеют довольно слабое представление о системе кэширования Друпала. До сих пор ни один разработчик не ответил мне правильно на все вопросы о хранилищах и назначении стандартного кэша, который включается в ядро Друпала уже достаточно давно. Мне кажется, уже пора раз и навсегда закрыть этот вопрос.

Я надеюсь, самые базовые знания о том, что такое кэш у вас есть. Если же нет – сначала надо прочитать вводную статью о кэше, а потом продолжать чтение текущей.

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

УрокБазовая информация о кэше и о работе с ним в Друпале

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