Dries Buytaert

Две недели назад на конференции DrupalCon в Париже, я представлял свою традиционную презентацию о состоянии Drupal. ]]>Видео презентации доступно на archive.org]]> и вы можете также ]]>скачать себе копию моих слайдов]]> (PDF, 8 MB).

Я не хочу портить сюрптиз, но в основном, состояние Drupal стабильное. :) Нам действительно стоит гордиться тем, что мы усовершенствовали Drupal 6 и мы доводим до совершенства Drupal 7. В презентации я также рассказывал о том, что значит для Drupal рост и на что будет скорее всего похожа следующий этап нашей жизни.

График выше сделан на основании статистики использования проекта, собранной на drupal.org. Подобной статистике всегда свойственно не полностью отображать картину. Это связано с тем, что только сайты, использующие модуль update status передают данные на drupal.org. Этот модуль является частью Drupal 6 и исталлятор предлагает пользователю включить этот модуль, когда Drupal впервые устанавливается. Использовать этот модуль не обязательно. Люди, которые обновляются с Drupal 5 даже не видят предложения установить этот модуль. К тому же, многие Drupal-сайты спрятаны за корпоратиными файерволами. В результате, мы не знаем точно сколько существует сайтов на Drupal 6.

В любом случае, основываясь на данных графика, которыми мы располагаем, мы можем предположить, что в январе 2010 будет около 240 тыс. сайтов на Drupal 6. Смотрите черную линия тенденции на графике. ]]>Коэффициент детерминации]]> показывает дисперсию набора данных, которая вычисляется для предсказанной модели. Его значение показывает как насколько предположения верны -- чем ближе к 1.0, тем лучше. Если Drupal 6 продолжит расти такими темпами как это было последние 9 месяцев, наши предположения должны быть достаточно точными. Это должно значить, что число сайтов на Drupal 6 удвоится за следующие 9 месяцев. Не плохо.

Я всегда верил, что лучший способ выростить Drupal это сделать ПО лучше и по этой причине мы продолжаем усердно работать над Drupal 7. До тех пор, когда будет релиз Drupal 7, есть ещё множество вещей, которые мы можем сделать, чтобы помочь людям начать использовать Drupal 6 -- от предоставления .zip-файлов вместо .tar-файлов, до редизайна drupal.org, до ещё большего распространения информации об успешных проектах на Drupal 6 и так далее. Ещё много барьеров, которые могут быть устранены и, устранение которых может обеспечить быстрейший рост.

Иногда очень хорошо делать списки. Приглашаю всех вас делиться списками "то, что я считаю, вам следует сделать" в комментариях к этой статье. Я советую сортировать списки в порядке важности, чтобы более важные были в начале. Если вы активно работаете над каким либо пунктом этого списка - также дайте нам знать. Бонусы за идеи, которые имеют максимальное влияние, требуют минимального усилия и дают большую пользу Drupal-сообществу. Штраф для людей, которые предлагают возможности Drupal 7, исходя только из своих интересов. На старт, внимание, марш!

Through a ]]>презентации от Николь Сьюлливан (Nicole Sullivan)]]>, старого члена команды Yahoo Exceptional Performance и со-автора книги O’Reilly по оптимизации производительности, я наткнулся на следующие данные:

• Amazon: 100 ms дополнительного времени загрузки привели к 1% отказов при покупках. (Источник: ]]>Грег Линден (Greg Linden), Amazon)]]>
• Google: 500 ms дополнительного времени загрузки привели к 20% уменьшеню запросов. (Источник: ]]>Marrissa Mayer, Google]]>)
• Google: уменьшение размера страницы на 30% привело к увеличению на 30% запросов карт. (Source: ]]>Мэрриса Мэйер (Marrissa Mayer), Google]]>)
• Yahoo!: 400 ms дополнительного времени загрузки привели к 5-9% увеличению людей, которые кликнули "Назад" перед тем, как страница была вообще загружена. (Источник: ]]>Николь Сьюлливан (Nicole Sullivan), Yahoo!]]>)

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

Давайте сделаем Drupal даже более стремительным! (Снимаю шляпу: ]]>Питер Ван Дюк (Peter Van Dijck)]]>)

После выхода Drupal 5, вас наверняка интересует какая версия Drupal быстрее -- последний релиз Drupal 4 или новый Drupal 5?

Пробная установка

Я установил Drupal 4.7 с 2 тыс. пользователей, 5 тыс. нод, 5 тыс. синонимов URL, 10 тыс. комментариев и 250 терминов словарей в 15 словарях.

Далее, я настроил главную страницу показывать 10 нод, включил некоторые блоки в колонке справа и слева, настроил несколько основных ссылок и добавил поиск в шапке страницы. Я также включил страницу контактов, с помощью модуля contact Drupal. Картинка ниже показывает как моя главня страница была настроена в результате.

Furthermore, I made an exact copy of the Drupal 4.7 site and upgraded it to the latest Drupal 5 release. The result is two identical websites; one using Drupal 4.7 and one using Drupal 5.

Benchmarks were conducted on a 3 year old Pentium IV 3Ghz with 2 GB of RAM running Gentoo Linux. I used a single tier web architecture with the following software: Apache 2.0.58, PHP 5.1.6 with APC, and MySQL 5.0.26. No special configuration or tweaking was done other than what was strictly necessary to get things up and running. My setup was CPU-bound, not I/O-bound or memory-bound.

Apache's ]]>ab2]]> with 20 concurrent clients was used to compute how many requests per second the above setup was capable of serving.

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

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

When presenting the benchmark results, I'll make a distinction between cached pages and non-cached paged. This will allow you to interpret the results with the dynamics of your own Drupal websites in mind.

Furthermore, a Drupal 5 installation has two caching modes: normal database caching and aggressive database caching. The normal database cache is suitable for all websites and does not cause any side effects. The aggressive database cache causes Drupal to skip the loading (init-hook) and unloading (exit-hook) of enabled modules when serving a cached page. This results in an additional performance boost but can cause unwanted side effects if you skip loading modules that shouldn't be skipped.

Through contributed modules, Drupal also supports file caching which should outperform aggressive database caching. I have not looked at file caching or any other caching strategies that are made available through contributed modules.

Результаты

Число страниц, которые Drupal может обработать за секунду. Чем больше, тем лучше.

На графике, приведенном выше, показано, что генерация страниц в Drupal 5 на 3% медленнее, чем в Drupal 4.7. В тоже самое время, при обработке кешированных страниц с использованием нормального кеширования в базе данных, Drupal 5 на 73% быстрее, чем Drupal 4.7, и на 268% быстрее, если используется агрессивное кеширование в базе данных.

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

The relative performance improvement of Drupal 5's normal database caching compared to Drupal 4.7's database caching. A miss rate of 0% means that all page requests result in a cache hit and that all pages can be served from the database cache. A miss rate of 100% means that all page requests result in a cache miss, and that we had to dynamically generate all pages.

The figure above shows the relative performance improvement of Drupal 5 compared to Drupal 4.7. We observe that Drupal sites with relatively few cache misses (typically static Drupal websites accessed by anonymous users) will be significantly faster with Drupal 5. However, Drupal sites where more than 1 out of 2 page requests results in a cache miss (typically dynamic Drupal websites with a lot of authenticated users) will be slightly slower compared to an identical Drupal 4.7 website.

To me these graphs suggest that for most Drupal websites, upgrading to Drupal 5 will yield at least a small performance improvement -- especially if you properly configure your page cache's expiration time. Furthermore, they suggest that for Drupal 6, we need to look at improving the page generation time of non-cached pages. Let's make that an action item.