производительность

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

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

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

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

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

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

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

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

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

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

Я уверен, что многие сталкивались с задачей, например, собирать какую-либо статистику и сохранять её в отдельную таблицу. Простейший пример: сохранять количество просмотров и комментариев к материалу за каждый день. А потом по этим данным построить график, который бы визуально отображал "популярность" материала за определённый период. Сама по себе задача простая - выбрать из двух таблиц данные и записать её в свою отдельную. Но когда у вас на сайте, скажем, 200 тысяч материалов, то вставка такого объёма данных может занять приличное количество времени. Но давайте поговорим о возможных вариантах записи этих данных.

Немного воды

Что делать, если сайт дохнет прямо на глазах? С чего начать, если вам подсунули полуживой проект с просьбой поднять его на ноги? Ответ выглядит немного по-капитански: анализ. Вам надо понять, где именно закралась проблема в производительности, которая мешает быстрой работе сайта. Сразу хочу сказать, что в этой статье я буду принимать на веру, что вы выбрали правильный хостинг, и проблема заключается не в нём. Безусловно, многие проблемы с производительностью на сервере можно решить докупив ещё железа, однако не каждый заказчик готов платить за это (хотя по подсчётам, докупить железа обойдётся гораздо дешевле, чем тратиться на специалиста по производительности, но кому это объяснишь ;)). Однако если же косяк с производительностью серьёзный - то он может съесть ресурсы даже докупленного железа, и тогда на вас очень обидятся. А если проблема окажется в клиентской части сайта - то хоть дата-центры скупайте, а у клиентов сайты будут тормозить.