Drupal 5: скорость

Аватар пользователя RISK RISK 25 февраля 2007 в 3:38

Перевод статьи «Drupal 5: performance» из блога Dries Buytaert (создателя Drupal) от 7 февраля 2007 года.


Drupal 5: скорость


С выпуском Drupal 5, вы могли бы задаваться вопросом, какая версия Drupal быстрее — последний выпуск в линейке Drupal 4.x или новый Drupal 5?


Тестовые настройки


Я установил Drupal 4.7 на сайт с 2000 пользователями, 5000 документами, 5000 псевдонимами для путей документов, 10000 комментариями и 250 терминами словарей в более чем 15 словарях.

Потом я настроил главную страницу так, чтобы на ней показывалось 10 документов, включил несколько блоков в обоих боковых меню, сделал несколько Primary links и добавил форму поиска наверх страницы. Я также установил страницу контактов используя стандартный модуль Drupal — Contact. Иллюстрация ниже показывает как была настроена моя главная страница.

Кроме того я сделал точную копию сайта на Drupal 4.7 и обновил его до последнего выпуска Drupal 5. Результат – два идентичных сайта; один на Drupal 4.7, другой на Drupal 5.

Тесты проводились на 3-х летнем Pentium IV 3Ghz с 2 Гб памяти с установленной ОС Gentoo Linux. Я использовал архитектуру по умолчанию со следующими программами: Apache 2.0.58, PHP 5.1.6 с APC и MySQL 5.0.26. Были сделаны только самые необходимые настройки. Мой тест ограничивала только вычислительна мощностью процессора, а не скорость каких-либо устройств или действий.

Чтобы определить, сколько запросов в секунду может обслуживать такая конфигурация, использовалась инструкция ab из Apache 2.x с 20 одновременно выполняющими запрос клиентами.


Кэширование страниц в Drupal


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

Представляя тестовые результаты, я разделил результаты для кэшируемых страниц и некэшируемых страниц. Такое разделение позволит вам прикинуть результаты для своих сайтов на Drupal.

Кроме того, Drupal 5 имеет два режима кэширования базы данных: нормальное и агрессивное. Нормальный кэш базы данных подходит для всех сайтов и не вызывает никаких побочных эффектов. Агрессивный кэш базы данных заставляет Drupal пропускать загрузку (init-hook) и выгрузку (exit-hook) включённых модулей когда обрабатывается запрос к странице. Это приводит к дополнительному ускорению загрузки страницы, но может быть причиной нежелательных побочных эффектов если вы пропустите загрузку модулей, которые не должны быть пропущены.

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


Результаты


Количество страниц обрабатываемых в секунду. Чем выше график, тем лучше.

Иллюстрация выше показывает, что генерирование страниц в Drupal 5 на 3% медленнее чем в Drupal 4.7. Однако, когда запрашивается кэшируемая страница при включённым нормальным режиме кэширования, Drupal 5 на 73% быстрее чем Drupal 4.7 и на 268% быстрее когда включен агрессивный кэш базы данных.

Что это значит для сайтов на Drupal 5? Эффективность использования кэширования страниц в Drupal зависит от множества параметров — времени истечения кэша, числа вошедших в свою запись посетителей, установок прав доступа и т.д. Для сравнения разных конфигураций Drupal, мы изменили настройки Drupal 4.7 и Drupal 5, таким образом, чтобы мы могли смотреть на работу для диапазона неудачного обращения в кэш страницы.

Относительное сравнение работы Drupal 5 в режиме нормального кэширования базы данных в сравнении с кэшированием в Drupal 4.7. Ошибки 0% означают, что все запросы страниц приводят к удачному обращению в кэш и что все страницы можно получить из кэша базы данных. Ошибки 100%, что все запросы страниц приводят к неудачному обращению в кэш и мы должны генерировать все страницы.

Иллюстрация выше показывает улучшение работы Drupal 5 по сравнению с Drupal 4.7. Мы видим, что сайты на Drupal с малым количеством неудачных обращениями в кэш (типичные статические сайты на Drupal, к которым обращаются анонимные пользователи) будут значительно быстрее на Drupal 5. Однако, сайты на Drupal где больше чем 1 из запросов на 2 страницы приводит к неудачному обращению в кэш (типичные динамические сайты на Drupal с большим количеством вошедших посетителей) будут немного медленнее по сравнению с точно таким же сайтом на Drupal 4.7.

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


Несколько комментариев к статье:


7 февраля 2007 — 19:25. 2bits — Khalid:
Вот три основных дополнительных кэширующих модуля:

Первые два работают со стандартной установкой Drupal. Последний с модернизированным API, с одним модулем, использующем его (модуль panels).



7 февраля 2007 — 19:43. ted:
Dries, превосходная работа!

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

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

Так, в то время как могло бы быть на 3 % медленнее запрос страницы в 5-ой версии, я буду утверждать, что страницы фактически открываются быстрее (например, загружается быстрее) из-за таких вещей как препроцессор CSS и mod_expires cashing, это лишь немногое из того, что можно сказать.



7 февраля 2007 — 21:27. Dries:
Вы правы Ted. Этот тест не даёт полной картины и не учитывает некоторые важные элементы внесённые в Drupal 5. Через несколько недель (как найду время), я попробую провести новый тест с более обширными/точными настройками — возможно основанный на Apache's JMeter. Посмеёмся! :)



8 февраля 2007 — 01:58. Том:
Я отложил обновление, но это успокаивает одно из моих опасений (что D5 был бы медленнее).

Я хотел бы увидеть такой тест:

  • CCK против родных типов документов
  • Views on/off
  • Statistics on/off

Материал как этот. Если у вас есть время, чтобы сделать какое-нибудь эталонное тестирование такого типа, я хотел бы видеть результаты! Я люблю компанию Views/CCK/Contemplate — очень мощная комбинация. Перефразируя Stan Lee из комикса Spider Man, «С мощной системой мы должны иметь мощную нагрузку на сервер». Я всегда любопытен, но насколько возросла нагрузка.



8 февраля 2007 — 07:19. Luiso:
Я думаю, что эти различия являются зверскими. Я не знаю, хороши ли статистические данные, но иначе я должен сказать, что люди проекта Drupal очень хороши. Я очень счастлив использовать их систему.



8 февраля 2007 — 08:15. Antonio Ortiz:
Я не был уверен относительно Drupal 5, но теперь я с ним.



8 февраля 2007 — 14:47. bhaskar:
Вы также пробовали и включали опцию «aggregate and compress CSS» в Drupal 5? Это должно дать двукратные выгоды, (a) это сохраняет пропускную способность и (b), это позволяет Drupal обрабатывать большее количество запросов в секунду.

Я очень интересовался бы статистикой пропускной способности для Drupal 4.7 и 5.0.

Спасибо за хорошую работу.



9 февраля 2007 — 16:45. Chris Johnson:
Я предпочел бы видеть тесты, которые ближе к настройкам, которые большинство людей видит в планах хостеров, скорее всего, что большинство сайтов на Drupal упадут.

Могло бы потребоваться некоторое исследование, чтобы получить точную картину относительно того, на что могли бы быть похожи «средние» настройки. Но мой опыт говорит, что большинство хостеров ещё не выполняет MySQL 5 и PHP 5 и также не выполняет APC.

Таким образом, мне любопытно, как этот же самый тест смотрится с MySQL 4.1 и PHP 4.3.10. На первый взгляд, это похоже на результаты, которые были бы подобными. Но возможно нет.

Я действительно рад видеть данные по работе кэша. Некоторые сайты, которые я делаю, имеют большинство трафика, сгенерированного анонимными посетителями. Другие сайты, с которыми я являюсь связанным, имеют 100% вошедших посетителей; анонимные пользователи могут только видеть страницу входа в систему. Похоже, что нам, вероятно, придётся оптимизировать наши сервисные стеки, когда мы попробуем переместить этих людей на D5.

0 Thanks

Комментарии

Аватар пользователя Natalie Natalie 25 февраля 2007 в 4:13

CCK и некоторые другие не совместимы с aggressive caching.
Посмотреть, какие из установленных модулей несовместимы, можно на странице кэширования.
---
---
All content management systems suck, Drupal just happens to suck less. -- Boris Mann at DrupalCON Amsterdam, August 2005.

Аватар пользователя garamond garamond 25 февраля 2007 в 12:50

Самый полезный материал... (во всяком случае для меня)

Автору огромный респект

...а что/кото есть Шекспир - можно ссылочку в студию? )

Аватар пользователя qman qman 25 февраля 2007 в 14:56

открой ссылку и увидишь, что это юмор такой.
быть кешу или не быть?
to cache or not to cache

а за перевод большое спасибо!