Basic performance. Заставим Drupal летать. Часть I

Basic performance. Заставим Drupal летать. Чать I

Всем привет! Давайте поговорим о производительности популярной CMS/CMF Drupal, а именно — о 7-й версии.

Многие не самые опытные пользователи ругают Drupal за медлительность. Мол, на каждый запрос Drupal всегда загружается целиком, подгружая все-все-все свои модули. В целом они, возможно, и правы, такая проблема у Drupal есть, но она решаема.

В Drupal почти весь контент, который предназначен для посетителей — это сущности (entity), будь то ноды, пользователи или термины таксономии. Давайте с них и начнем.

Генерируем 1000 пользователей с помощью модуля devel_generate, который входит в devel и замеряем время их загрузки из БД.

image

Из примера видно, что эта операция занимает 30 секунд, что на самом деле не очень-то и хорошо. Что ж, как раз на этот случай в Drupal встроена собственная система для кеширования сущностей. Давайте посмотрим на неё в работе.

image

При повторном запуске эти пользователи загружаются уже за 2 секунды, что ж, молодец Drupal, но можно и лучше.

Скачиваем и включаем пару модулей (Entity cache и Memcache).

Модуль Entity cache позволяет кешировать стандартные сущности Drupal с использованием Cache API.
Memcache предоставляет возможность перенести заботу о кеше с MySQL на Memcached сервер, который хранит данные в оперативной памяти и соответственно быстрее с ними работает.

image

И — сходу успех, первый запуск выполняется всего за 2,8 секунды вместо 30. Идем дальше.

image

Повторный запуск, при котором данные достаются из кеша Memcached сервера выполняется за 0,4 секунды. Довольно неплохо в сравнении с кеширование по умолчанию в Drupal.

Однако, Memcached не единственный, подобные вещи может делать Redis.
Отключаем модуль Memcache и устанавливаем модуль Redis.

image

Первый запуск снова долгий, потому что кеш сперва сформировывается. В итоге — 2,2 секунды, пока это лучший результат.

image

0.35!

Таким образом, мы добились увеличения производительности в 13 раз в случае с первым запуском и в 5 раз в случае, когда данные берутся из кеша.

К сожалению, на хостинге не всегда есть возможность установить дополнительно сервер Memcached или Redis. В данном случае можно обойтись только модулем Entity cache.

image

Первый запрос исполняется довольно долго. Это опять же связано с генерацией кеша.

image

Зато все последующие выполняются меньше чем за секунду.

Отсюда можно сделать вывод, что модуль Entity cache — это must have модуль на любом Drupal сайте. Исходя из возможностей его можно дополнить Redis’ом.

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 18

    0
    А что скажите насчет Boost? Если сайт рассчитан в первую очередь на анонимов (который просто читают, но не регистрируются, ничего не комментят и т.д.), то с ним сайты вообще летают, разве нет?
      +1
      Если сайт предназначен только для анонимов, то и встроенного кеширование страниц для анонимных пользователей будет вполне достаточно.
        0
        Если хотите быстрее буста, то вам поможет Varnish
          0
          У меня был печальный опыт с Boost. После его установки сайт на 1000+ страниц за два дня полностью выпал из кэша Яндекса. С гуглом всё нормально, специально подождал до апа и у гугла ничего не поменялось. После отключения модуля Яндекс заново сайт индексировал пол года. Из того, что показало расследование, апач сообщал один размер страницы, а отдавал другой. Кто виноват — непонятно. Гуглу, как оказалось, на это наплевать, а вот Яндекс пометил все страницы как битые и удалил из кэша.

          И в принципе, даже если откинуть эту проблему — тут идёт кэширование диском, да ещё и создаётся туева хуча файлов. Это всё очень сильно нагружает ФС. А если юзать memcashed или Redis — кэш живёт в оперативке, при чём возможно даже на отдельной машине. Для тяжеловесных проектов очень даже. Видел даже вариант использования MongoDB в качестве кэша — скорость в 2-3 раза ниже чем у memcashed (при условии хранения данных в оперативке), но потенциально больше возможностей.
            0
            Странно, первый раз слышу о такой проблеме с Boost'ом. Сам использую его на 6 сайтах объемом 300-800 страниц, и с посещаемость несколько тысяч человек в день (99% — анонимы). Нравится, что страницы для них грузятся практически мгновенно. Но как раз опасаюсь побочных эффектов из-за файлового кеширования.
            Поэтому интересует, что лучше использовать для сайтов объемом до 2000 страниц и с посещаемостью до 20 000 человек в день (99% — анонимы). Мне кажется, что в данном случае Boost — оптимален с точки зрения производительности. Или нет?
          +1
          Спасибо, но хочется больше, ждём вторую часть.
            0
            Вот еще совет:
            php eval работает неплохо, но достаточно медленно на циклах (что естественно).
            Решение: заверните тело цикла в функцию. Прирост производительности гарантирован ))
            0
            Какие плюсы\минусы у Entity cache? Ведь они есть? Иначе бы был включен в коробку наверное?
              +2
              Entity cache включен в ядро в восьмерке.
                0
                Появился после выхода Drupal 7, умеет кэшировать сущности в Redis например. Есть свой API. Минусы не замечены, кроме малого количества примеров.
                +1
                Статья с серьёзной ошибкой.
                при включении мемкэша/редиса вдруг с самого первого раза начинает всё за 2 секунды работать вместо 30ти, что не может быть верным. Без кэша-то user_load() всё равно все данные из бд тянутся. И не редис, не мемкэш это ускорить не могут. Максимум где здесь можно получить ускорение — за счёт скорости записи в память вместо бд. Но это никак не разница в 28 секунд.
                это я вот к этому «И — сходу успех, первый запуск выполняется всего за 2,8 секунды вместо 30».
                это нереальное значение. А кто-то верит.
                это явно не запуск с нуля, а чтение каких-либо данных из кэша.
                ©Spleshka
                  0
                  Тут явно I/O просаживается, а не drupal. Помониторьте работу БД и I/O, ясное дело что Redis даст прирост. Хостера поменяйте и будет счастье, так как с 2014 года и даже раньше все вменяемые хостеры перешли на SSD. user_load грузит не просто пользователя в виде одной записи из БД, а все его поля которые хранятся в отдельных таблицах для поддержки версионности. Т.е. для загрузки 1000 пользователей нужно сделать раз в 5 больше запросов (они всё же быстрее выполняются чем если бы всё сериализовано хранилось в одной таблице) к б.д. и база мрёт на I/O. Поэтому Drupal тут ни при чём, статья любопытная, но не о чём.

                  Для кэширования статей в Drupal рекомендую статью: Отдаём кэш анонимов без поднятия бэкэнда. Drupal 7 + nginx + memcached — drupalace.ru/lesson/otdayom-kesh-anonimov-bez-podnyatiya-bekenda-drupal-7-nginx-memcached от нашего общего товарища с ником: Spleshka.
                    0
                    Прирост производительности при первом запросе действительно большой и получается он за счёт отсутствия INSERT запросов в таблицы кеша друпала (кеш полей и кеш сущности).
                    0
                    На самом деле кеширование — очень даже интересный аспект и не только в Друпале. При использовании кеширования самих сущностей (Entity), нужно быть очень акуратным, именно в том плане, что после подключения кеширования необходимо записывать/читать данные только используя Ваш код с кеширующим слоем, и ни в коем случае нельзя уже тогда менять прямо в БД, или через другие скрипты.
                    Хотел бы еще добавить, относительно выбора «Cache Storage»: в частности, большинство стают перед выбором Redis vs Memcache(d).
                    Здесь необходимо понимать, что такое Memcache(d) и что такое Redis

                    Memcached — это key & value хранилище. Имеет ряд недостатков, главным из которых есть выброс старых ключей, если есть нехватка памяти. То есть, к примеру у Вас там только 16 Мб. Вы загрузили туда кешей на все 16 Мб. После этого, если Вы будут вставлять в него новые данные, старые будут удалены. Во время перезагрузки Вы тоже потеряете данные.

                    Redis — это не только key & value хранилище, но и полноценное хранилище для других типов данные, таких как HASH, LIST. При этом, есть очень хорошая поддержка Lua-скриптов и другого нативного функционала, что иногда очень упрощает жизнь. Большой плюс — это «сливание данные» на винт (если указано в конфиге), в результате, данные при перезагрузке потеряны не будут. Также в нем очень хорошо распределяется память (я бы сказал лучше чем у memcached). Выбор на этот «монстр» нельзя делать только для использования key & value!

                    Моя практика показывает, что кеширования сущностей, дает слабоватый прирост производительности ПО СРАВНЕНИЮ с HTTP кешированием. Было бы очень интересно посмотреть на возможности кеширования Varnish, Nginx + Memcached (или другие связки) в самом Друпале.
                      0
                      Drupal 7 + nginx + memcached получается быстрее чем с Varnish, так же памяти меньше расходуется. Точные замеры не делал. Как настроить, написал топиком выше.
                        0
                        Я видел что написали, спасибо.
                        Я не думаю, что nginx + memcached будет быстрее чем Varnish. Здесь скорее уже надо полноценно замерять.

                        В большинстве случаев думают что Варниш будет хуже работать, так как пишет кеши на диск. Но не следует забывать, что раздел можно подцепить на оперативную память, и тогда он точно также будет писать как и Memcached.
                        Также, в Варнише есть очень прикольная штука ESI — что может в разы увеличить производительность некоторых разделов сайта/портала.
                          0
                          Отвечу какие вижу изъяны в Varnish, хотя ESI в нём замечательная штука, но предпочитаю с помощью JS грузить части страниц кэшируя их в Nginx + Memcached (получается почти то же самое, но руками делать нужно больше). Итак по изъянам:

                          1. Varnish будет медленнее из за I/O чем Memcached. Виртуальный диск это уже не для среднего уровня.
                          2. Memcached можно развернуть в кластер с помощью mcrouter (https://code.facebook.com/posts/296442737213493/introducing-mcrouter-a-memcached-protocol-router-for-scaling-memcached-deployments/).
                          3. Varnish менее производительный чем Squid (https://ru.wikipedia.org/wiki/Squid).
                          4. Когда серверов много, то на основе куки можно определить с какого сервера только, что запрашивал страницу пользователь и направить на получение страниц именно туда его, делает это nginx. Т.е. под разные языки сайта стоят разные сервера и на входи балансим пользователя на нужный сервак а там из Memcached отдаём статику. Для очень большого проекта это очень удобно.

                          В остальном для средних по размеру сайтов он Великолепен. Ставится минимум настроек и сразу получается ускорение которого достаточна для большинства сайтов. Так же например можно для Drupal поставить модуль SDN в котором настроить роутинг картинок на поддомен и на поддомене раздавать картинки через Varnish кэшируя их в памяти. В таком случае так же получаете хорошую скорость загрузки всей страницы.
                        +1
                        В частности друпальный модуль полноценно работает с редисом через HASH. И по сравнению с мемкешем правильно обрабатывает очистку кеша по вайлдкарду.

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое