Вам необходимо включить JavaScript в Вашем браузере для посещения сайта. Приносим извинения за неудобства.
Перейти к основному содержанию
Уважаемые коллеги! Новая версия сайта работает в тестовом режиме. Информация появится с ближайшие дни.
Модуль Flag - причина медленной работы для Drupal 9

Сайт на Drupal 9 стал медленно работать? Возможно установлен модуль Flag

15 апреля 2021 г. 10:11

Всем привет!

На связи сайтсервис.рф, и сегодня хотим рассказать о неожиданности, которая нас подстерегала после запуска в экcплуатацию сайта на Drupal 9. Сайт разрабатывался для замены старого ресурса для крупного российского производителя и поставщика стройматериалов.

Основной причиной разработки нового сайта была очень низкая производительность старого сайта. Предыдущий сайт медленно открывался, был неинформативен в плане отзывчивости интерфейса и требовал достаточно большого количества ресурсов даже для такой неспешной работы. Интерфейс администратора был рассчитан на небольшой набор данных. Редактирование многотысячного каталога, содержащего десятки полей, там было крайне затруднительно.

За четыре недели мы разработали новый сайт на базе CMS Drupal 9, мигрировали каталог и все данные, создали удобную панель администрирования для быстрого управления данными и в согласованный момент запустили новый сайт на старом домене. Разработанный сайт открывался почти мгновенно благодаря встроенным и дополнительным возможностям кеширования Друпала и различному набору оптимизаций фронтэнда и бекэнда. Наши специалисты подобрали виртуальный сервер и настроили среду, чтобы обеспечить максимальную производительность.

Какое же было удивление нашего руководителя проекта, когда спустя три недели после публичного запуска заказчик стал жаловаться, что сайт очень медленно работает. Не переключил ли кто-то домен обратно на старый сайт - закралась мысль. Но это действительно был новый сайт. И он жутко тормозил.

Исследование логов показало, что трафик не выходил за пределы расчетного: 200-300 тыс. запросов в сутки, распределенные примерно поровну. Мы перепроверили все настройки кеширования, настройки веб-сервера, PHP и СУБД. Все было абсолютно штатно.

Мониторинг сервера показал, что СУБД съедала 95-100% вычислительного ресурса каждого ядра виртуалки. Поэтому далее мы исследовали друпаловскую базу на предмет аномалий. Обратили внимание, что таблица модуля Flag (flagging) состояла из 670 тыс. записей. Совсем не много по меркам MySQL, но она занимала объем 200 мб, что на фоне остальных данных было достаточно большим показателем.

Модуль Flag (Флаг) для CMS Drupal позволяет пользователям помечать понравившиеся материалы (статьи, товары и т.п.) метками (флагами), формируя таким образом список желаний, "избранное" или любой другой пользовательский список материалов сайта. На нашем сайте пользователь помечает материалы путем нажатия на ссылку напротив нужной позиции, а потом может просмотреть, распечатать или поделиться отобранным списком. По требованию заказчика данный функционал доступен даже для анонимных пользователей. Поэтому привязка идет не к учетной записи, а к сессиям.

Мы пробовали удалить все пользовательские "флаги" через интерфейс Drupal. Это либо не давало эффекта, либо удалялись пару десятков тысяч записей. Но в любом случае заканчивалось ошибкой 500. Поэтому сделав все необходимые резервные копии, мы просто выполнили функцию truncate в Mysql, т.е. полностью очистили таблицу, сбросив счетчики.

И о чудо, сайт вернулся к исходной производительности. Нагрузка на CPU упала до 5-10% при средней посещаемости. Это подтвердило, что проблема была в объеме данных таблицы flagging.

Исследование просторов интернета, а конкретно инцидентов по модулю Флаг показали, что такая проблема существует не только у нас и она известна:

https://www.drupal.org/project/flag/issues/2960572

Даже существует патч. Мы проверили и действительно создание корректных индексов решило проблему. Даже с 700 тыс. записей в таблице flagging сайт чувствует себя очень уверенно.

Хотя такой объем анонимных данных явно излишний. Опять же логи показали, что некоторая часть флагов, это результат работы ботов, а не людей. Несмотря на атрибут nofollow и закрытие от индексации раздела /flag/ в robots.txt, роботы активно добавляют товары в избранное. Решение вопроса ограничение доступа ботам это следующий этап.

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

Если ваш сайт на Drupal начали внезапно тормозить, проверьте не является ли модуль Flag этому причиной.

Симтпоматика:

  • Сайт медленно загружает страницы, даже при "максимальном" кешировании;
  • Особенно медленно ставятся/снимаются флаги;
  • MySQL создает высокую нагрузку на процессор;
  • Таблица flagging содержит десятки или сотни тысяч записей (в зависимости от ресурсов вашего сервера).

Решение:

  • Применить патч к модулю Flag;
  • Задуматься над целесообразностью хранения такого объема флагов (есть ситуации, когда эту информацию нельзя просто убрать).

 

Простой текст

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Строки и абзацы переносятся автоматически.
  • Адреса веб-страниц и email-адреса преобразовываются в ссылки автоматически.