Old-Site, Drupal, Статья, Оптимизация 3 января 2010

Разработка сайта на Drupal. Часть 6. Оптимизация Друпал

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

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

Методы оптимизации «из коробки»

Сначала рассмотрим, что предлагает Drupal в стандартной поставке. Настройки производительности задаются в меню Administer — Settings — Performance (admin/settings/performance). Первый раздел настроек — страничный кэш, в Drupal эта разновидность кэширования отвечает за показ страниц анонимным посетителям сайта. При включении нормального режима кэширования полностью сгенерированная страница сохраняется в кэше (по умолчанию это таблица БД) и отдается анонимным посетителям, пока в кэш не будут помещены новые данные. Число запросов к СУБД при этом уменьшается до нескольких штук на страницу.

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

Отметим, что полностью выключить кэширование в Drupal нельзя. Функция в настройках производительности отвечает только за страничный кэш, но Drupal также кэширует меню, фильтры ввода, блоки; дополнительные модули могут создавать свои кэши — все эти данные сохраняются в отдельных таблицах БД. Внизу страницы настроек есть кнопка очистки кэша, которая очищает только кэш страниц.

Последний режим в этом разделе — компрессия страниц. Современные браузеры позволяют получать компрессированные данные, снижая объем данных, передаваемых по сети, в среднем в 6–8 раз — разумеется, если сервер умеет отдавать данные в таком сжатом виде. При активации этого режима сжатие выполняется на уровне Drupal, т. е. средствами PHP. В то же время, лучше поручить эту операцию Web-серверу, поскольку он справится с ней эффективнее. Эта операция в Drupal сделана на случай, когда нет возможности включить компрессию страниц на Web-сервере.

Практически из той же серии другой раздел настроек оптимизации — оптимизация трафика. Здесь можно включить слияние CSS и Javascript, отдаваемых сайтом. Различные модули сайта могут добавлять свои стили и скрипты на страницы, в результате запрос страницы браузером влечет за собой десятки мелких файлов со стилями. Эффективнее объединять все файлы в один и отдавать его один раз, что и делает Drupal при включении опций на этой закладке. Держать настройки слияния выключенными имеет смысл только во время разработки сайта, когда стили и скрипты часто меняются и дополняются новыми.

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

Дополнительные модули для оптимизации

Drupal позволяет подменять стандартный механизм кэширования альтернативными реализациями, что и используется несколькими модулями, предоставляющими свои методы кэширования данных. Обычно суть всех этих модулей сводится к подмене механизма хранения кэша — вместо БД используются хранение в файлах или в оперативной памяти.

Наиболее комплексное решение предоставляет модуль cacherouter. Он реализует механизмы кэширования в файлы, в память через «демон» memcached либо использование памяти акселераторов APC и XCache. Как уже отмечалось, Drupal использует в БД разные таблицы под кэши различного назначения. Удобство модуля cacherouter в том, что можно указать для каждого вида кэша, где он должен храниться, например комбинировать кэширование страниц в файлах с кэшированием блоков в memcached.

Способы снижения нагрузки на хостинг

Один из ресурсоемких компонентов Drupal — механизм поиска и индексации контента. Для ускорения поиска по содержимому сайта Drupal строит поисковый индекс, эта операция производится в фоне, при срабатывании планировщика заданий, но отбирает свою долю ресурсов. Реализация поиска в Drupal неплоха и приемлема для большинства небольших сайтов, но при большом объеме контента и высокой посещаемости реализация поиска на PHP может не справляться с нагрузкой. Эффективнее использовать сторонние поисковые системы. Простейший выход здесь — интеграция с поиском Google. Но по многим причинам это не всегда удачный выход. Однако есть великолепные OpenSource-решения для поиска, которые удобно использовать при условии их интеграции с сайтом. Для Drupal разных версий предлагались модули интеграции с несколькими поисковыми движками, в частности для Drupal 6 есть модуль интеграции с поисковым движком Sphinx, выпускаемым под лицензией GPL. Sphinx реализован на языке Cи и предлагает быстрое и масштабируемое решение для поиска по большим объемам данных. В примерах на сайте разработчиков упоминаются хранилища данных емкостью более терабайта и сайты с потоком поисковых запросов в несколько миллионов в день. Даже если объемы данных и число ожидаемых поисковых запросов меньше, использование внешнего поискового движка позволит разгрузить Drupal. Модуль sphinxsearch (http://drupal.org/project/sphinxsearch) заменяет стандартный модуль search на интерфейс к поисковому движку Sphinx. Он сложнее в конфигурировании (благодаря обширным настройкам, предлагаемым в Sphinx), но позволяет реализовать методы поиска, которые имеются в Drupal: по документам, комментариям, пользователям и таксономии. Модуль в настоящее время находится в разработке, но версия для Drupal 6 уже доступна для загрузки.

Стоит помнить, что оптимизация работы Drupal — только один из этапов в оптимизации сайта. Настройки Web-сервера и СУБД, акселерация PHP, настройки ОС и «железа» — все это влияет на работу сайта, поэтому оптимизация работы системы должна проводиться на всех уровнях.

Ссылки на другие части этой статьи:

Содержание всех статей: /blog/2010/my-drupal-articles