Пользователь
0,0
рейтинг
23 мая 2014 в 16:28

Разработка → Как мы ускоряли Drupal Commerce tutorial

photo's author: Corrie...Disclamer: если все, о чем написано далее, покажется для вас «детским лепетом» и совсем уж очевидными вещами, будем рады поработать с вами :)

Предыстория: около года назад наша небольшая, но гордая веб-студия получила заказ на разработку интернет-магазина printer38.ru. А так как мы специализируемся на CMS Drupal, в качестве модуля интернет-магазина решили использовать Drupal Commerce.

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


Если вы когда-нибудь подбирали принтер через Яндекс Маркет, вы должны представлять количество полей у подобных товаров. У нас для каждого товара в базе хранится 184 поля с характеристиками — от скорости печати до наличия возможности работы от аккумулятора.

Лишь малая часть полей товара...

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

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

Начались классические «танцы с бубном» — оптимизация MySQL, кэширование запросов, жесткий дебаггинг и профайлинг :)
Попытаюсь в этом посте восстановить последовательность действий по оптимизации, в результате которых нам удалось добиться приемлемой скорости загрузки страниц сайта.

1. Подключение модуля memcached

На любой «пинок» в сторону Drupal — мол, медленно работает, — его евангелисты отвечают «Use cache». Собственно, этим и занялись.
Стандартное кэширование Drupal, как известно, сохраняет кэш в ту же базу данных, что в нашем случае изначально было бесполезно.
Поэтому решено было держать кэш в оперативной памяти — благо, на нашем сервере ее было достаточно. Для этой цели использовали memcached на сервере и memcache_storage в Drupal (спасибо Евгению Spleshka за замечательный модуль).

После переноса данных в кэш все стало шевелится заметно быстрее, но все же не так, как хотелось. Разбираемся дальше…

2. Вынос кэша форм в memcached

В один из пасмурных дней мы обратили внимание на какой-то нечеловеческий размер таблицы cache_form — более 7Gb! Таблицу почистили, однако она снова стала расти молниеносными темпами.

Причина оказалась простой: каждая кнопка «Купить» в нашем каталоге товаров — это мини-форма, которую Drupal считает необходимым положить в кэш, попутно утягивая туда «все, что попадется под руку». А при использовании AJAX-кнопок (как в нашем случае) кэш начинает расти на порядок быстрее. Вдобавок к этому, по какой-то ведомой только разработчикам Drupal таблица cache_form не очищается автоматически, как это происходит с другими таблицами кэша.

Понять проблему — значит на 90% решить ее :)
cache_form был так же вынесен в memcached (вопреки рекомендациям хранить ее в базе данных).
Для периодической очистки таблицы использовали модуль optimizedb (теперь ставим его по умолчанию на все сайты с Drupal Commerce).
Проблему с AJAX-кнопками решил xandeadx, но его решение появилось только спустя пару месяцев после описанных мной действий, поэтому в то время мы не могли использовать его в нашем проекте. ;)

Главная страница сайта стала «летать». Однако с каталогом все еще беда — страница открывается 2-3 минуты. :(

3. Отказ от полей во views

«Друзья» — как то сказал наш самый опытный разработчик, — «Мы все знаем, что Drupal кэширует ноды. Так почему мы не пользуемся этим, и заставляем каждый раз views дергать все данные из базы данных?».

Сказано — сделано. Каких-то 1-2 часа работы команды на перепиливание вьюсов и переверстывание страниц, и — о чудо — удалось снизить загрузку страницы каталога до «каких-то» 40-50 секунд. Пользователи подождут, верно ведь? Им торопиться некуда…

4. Очередная попытка оптимизации — отказ от стандартного пагинатора, подключение кэширования во «вьюсе», кэширование сущностей (entity)

Дальше программисты опять достали бубен со шкафа (благо, далеко убрать не успели).

У умных людей прочитали, что проблемой «тормозов» может быть стандартный пэйджер (он же пагинатор, он же paging). Вылечили установкой модуля views_litepager.

Заодно поставили модуль commerce_entitycache, который должен кэшировать entity (сущности) объекта product.

Однако все эти «пляски» дали лишь небольшой прирост в скорости.



Самый существенный результат дало подключение кэша для views, однако и здесь оказалось не все гладко. Во-первых, при кэшировании запроса наш фильтр товаров стал выдавать один и тот же результат, пришлось отключить. А во-вторых, ускорение наблюдалось только при загрузке «чистой» страницы, когда ни один фильтр не выбран. Стоило выбрать хотя бы один чекбокс, и можно было опять идти пить кофе в ожидании загрузки страницы.

Page execution time was 69728.43 ms
М-да…

6. Почти победа. Ручная оптимизация запроса views

В определенный момент мы поняли, что пора действовать жесткими методами. А именно — детально изучить, что же такое views запрашивает в базе данных, что на формирование результата уходит не менее 30 секунд.

И увидели мы примерно такое:

...
INNER JOIN
   {commerce_product} commerce_product_field_data_field_product_reference 
      ON field_data_field_product_reference.field_product_reference_product_id = commerce_product_field_data_field_product_reference.product_id  
INNER JOIN
   {field_data_commerce_price} commerce_product_field_data_field_product_reference__field_data_commerce_price 
      ON commerce_product_field_data_field_product_reference.product_id = commerce_product_field_data_field_product_reference__field_data_commerce_price.entity_id 
      AND (
         commerce_product_field_data_field_product_reference__field_data_commerce_price.entity_type = 'commerce_product' 
         AND commerce_product_field_data_field_product_reference__field_data_commerce_price.deleted = '0'
      )  
INNER JOIN
   {field_data_field_printer_a4_speed_2} commerce_product_field_data_field_product_reference__field_data_field_printer_a4_speed_2 
      ON commerce_product_field_data_field_product_reference.product_id = commerce_product_field_data_field_product_reference__field_data_field_printer_a4_speed_2.entity_id 
      AND (
         commerce_product_field_data_field_product_reference__field_data_field_printer_a4_speed_2.entity_type = 'commerce_product' 
         AND commerce_product_field_data_field_product_reference__field_data_field_printer_a4_speed_2.deleted = '0'
      ) 
...


и так — для каждого поля, участвующего в фильтрации.
Да, JOIN'ов много. Но не могут они отрабатывать ТАК долго!
«Постойте, а зачем нам проверка на тип? У нас же все сущности с id товара должны быть 'commerce_product'?»

Взяв в руки IDE, пишем небольшой хук в своем модуле:

/**
 * Implementation of hook_views_query_alter
 * @param type $view
 * @param type $query 
 */
function mymodule_views_query_alter(&$view, &$query) {
    if ($view->name == 'catalog_v_2') { 
        foreach ($query->table_queue as $key=>$item) {
               $query->table_queue[$key]['join']->extra=array();
        }                                                
    } 
}


То есть просто «выкидываем» все дополнительные условия из JOIN (в том числе непонятный deleted, который, по нашему опыту, всегда равен нулю).
Можно было совсем избавиться как минимум от одного JOIN'а, но была уже поздняя ночь, и всем хотелось спать :)

Сравним:

Before: 34665.211 ms
After: 0.13 ms

Да, «нет предела совершенству», поэтому мы продолжаем эксперименты по оптимизации. Надеемся, наш опыт будет кому-то полезен, и на свет появится много удобных и быстрых интернет-магазинов на Drupal Commerce :)
Сафин Антон @box1024
карма
5,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

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

Самое читаемое Разработка

Комментарии (74)

  • +13
    2 вопроса:
    Что осталось от Drupal?
    И стоило ли брать Drupal?
    • +2
      От Drupal осталось всё :)
      Удобная админка, быстрое создание и изменение вьюсов, гибкость темизации, огромная база знаний…
      Если бы делали проект с нуля (даже на каком-нибудь framework'е), ушло бы на порядок больше времени.

      По второму вопросу — не знаю, честно.
      Возможно, стоило попытать счастья с какой-нибудь другой CMS, «заточенной» под магазин — например, Magento. Однако в данном случае нам было проще работать с тем продуктом, который мы хорошо знаем.
      • +3
        > Если бы делали проект с нуля (даже на каком-нибудь framework'е), ушло бы на порядок больше времени.

        На порядок больше времени ушло бы в том случае, если бы вы с выбранным фреймворком работали впервые. У опытной и имеющей наработки команды (да даже у одного опытного программиста) времени бы ушло, наоборот, меньше.

        Например, сформулировать в ORM вашего фреймворка зависимости моделей друг от друга — быстрее, чем пытаться сделать то же самое в вэб-интерфейсе Drupal Views. Вот, для примера, как это делается на Ember: emberjs.com/guides/models/defining-models/#toc_defining-relationships. Это правда очень просто и быстро. Вкуривать же, почему Views выдает пустую выборку при попытке сделать запрос с фильтрами и join'ом двух-трех таблиц, можно часами.
      • –2
        > Удобная админка…

        Помойму это худшая админка для конечного пользователя
  • +1
    Во-первых, при кэшировании запроса наш фильтр товаров стал выдавать один и тот же результат, пришлось отключить.
    Пропатчить вьюс можно
    drupal.org/node/1055616#comment-8610445
    • 0
      О, супер, спасибо!
    • 0
      Хотя, для фильтров у которых нет фиксированных значений наверно не стоит кэш включать. Количество комбинаций получится огромным.
    • +1
      Патч добавлен в последней версии Views 3.8:
      #1055616 by johnv, Dmitriy.trt, tomgf, ygerasimov, dawehner, zipymonkey, citlacom, tim.plunkett, vaartio, hefox: Query arguments should be replaced before generating cache ID.
  • +1
    Пробовали проиндексировать чем-то вроде Apache Solr или Sphinx и для представления использовать проиндексированные данные? В качестве бонуса получите Фасетный поиск и не только.
    • 0
      Да, с самого начала мы так и делали. Потом по какой-то причине отказались от этого варианта и все переделали.
      Уже сложно вспомнить, в чем конкретно были проблемы. Но по большому счету главная причина — в том, что логика работы фильтров через фасеты не соответствовала прототипу сайта.
      • 0
        Фасеты использовать не обязательно же. С базы снимается нагрузка при поиске по вашим вьюшкам.
  • +8
    Описанные в статье пляски с бубном — одна из четырех причин, по которым я забил на Drupal и стал учить EmberJS и Rails.

    Другая причина — в отсутствии внятного цикла development -> staging -> production. Развитие уже запущенного сайта — лютая морока.

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

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

    Спасибо, наигрался, сделал выводы, пора двигаться дальше.

    Я не понимаю людей, которые упорно сидят на Drupal и опирают на него свой бизнес. Попробуйте пару уикендов поковырять Ruby/Rails, Python/Django, JS/Derby. Когда вы почувствуете, как вэб-приложение поднимается из нескольких элегантных строчек кода и послушно делает всё, что вы ее попросите понятным языком — вы уже не сможете смотреть в сторону Drupal.

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

    Я не могу сказать, что Drupal тянул меня на дно, это было бы сгущением красок. Напротив, он был моим автобусом в мир вэб-разработки. Но автобус ходит по одному и тому же маршруту. Пересаживайтесь с автобуса в личный автомобиль, на котором вы можете ездить куда угодно. Возьмите пару уроков вождения (это бесплатно и не больно) — и вы станете удивляться, как можно было полжизни пользоваться автобусом.

    PPS Статью плюсанул.
    • +1
      Я не понимаю людей, которые упорно сидят на Drupal и опирают на него свой бизнес.
      Потому что этот бизнес приносит им деньги, а эти деньги рождают спрос на друпал. Делать мало бюджетные сайты на рельсах или джанго сомнительное удовольствие. Заказчик платит за результат, а результат это качественный сайт. На каком ЯП или фреймворке сделан этот сайт мало кого интересует. Главное, что этот сайт работает и выполняет функции для которых он создавался.
      • +4
        Так я про типовые сайты-визитки и не спорю.

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

        Вот ты понимаешь, что твои Жигули совершенно не справляются. Ты можешь пойти пересесть в Ауди, но вместо этого ты почему-то предпочитаешь мучиться, перебирая у Жигулей коробку, растачивая цилиндры и заменяя карбюратор на самодельный девайс, изготовленный рукастым соседом. Причем, Ауди выдают бесплатно, надо только научиться его водить, а обучение вряд ли займет больше времени, чем вечные мытарства с Жигулями.

        Я считаю, что причина у этого только в косности мышления. Сложно заставить себя взяться за незнакомый Ауди с этими непонятными инжекторами, турбонаддувами, АБСами, коробками-автоматами и пиндосскими подушками. Родной Жигуленок «ближе к телу», к тому же Петрович говорит, что Ауди коробки-автоматы делать не умеет.
        • –3
          Так я про типовые сайты-визитки и не спорю.
          Малобюджетные сайты это намного больше чем «типовые сайты визитки».
          Можно условно определить их объёмом работы: 2-3 недели для одного друпал разработчика средней квалификации (включая вёрстку). Это огромный сегмент рынка, в котором джанго и рельсы почти полностью отсутствуют ввиду своей неконкурентноспособности. Наивно полагать все фрилансеры и студии которые «держат» это нишу на рынке имеют закостенелый мозг и не понимают, что ауди лучше жигулей.
          • +2
            Еще раз. Я со сказанным вами не спорю, но когда над одним сайтом работает не один вэб-мастер, а несколько программистов (цитаты из статьи: «Дальше программисты опять достали бубен со шкафа», "«Друзья» — как то сказал наш самый опытный разработчик"), то это уже не тот уровень, о котором вы говорите.
            • 0
              Ну а причем тут количество программистов в проекте? Что бы оценить уровень проекта достаточно просто зайти на сайт (ссылка есть в топике). Конкретно для этого проекта, вполне вероятно, можно было использовать какую то другую платформу вместо друпала. Разумеется при наличие программистов с соответствующим опытом.
              В статье описаны проблемы с производительностью, которые возникли при разработке данного конкретного магазина. И способы их решения. Но со стороны это больше похоже на расказ про то как мышки плакали и продолжали есть кактус. )
              • +1
                Но со стороны это больше похоже на расказ про то как мышки плакали и продолжали есть кактус. )

                Об этом я и говорю! Сайт действительно не выглядит дорогим. Но он становится дорогим, когда к его разработке привлекается несколько программистов, а потом вылезают такие вот косяки, для решения которых требуется квалификация более глубокая и специализированная, чем квалификация Rails-программиста среднего пошиба.
              • +1
                Я уже не говорю о том, что развитие работающего Drupal-сайта — очень нетривиальная задача. Допустим, заказчик попросит добавить в каталог новые типы товаров и новые фильтры (не размножая при этом content types).

                Но как это делать, если сайт уже в продакшене?

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

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

                Что остается? Либо внучную воспроизводить фичи на продакшене, удваивая объем работы и показывая в процессе недоделанный сайт посетителям, либо вырезать отдельные таблицы и приживлять их на продакшен и изобретать кастомные миграции. Оба способа — для настоящих поедателей кактусов.
                • 0
                  Тут стоило бы уточнить что вы имеете ввиду под типом товара: тип товара, тип ноды, или категорию товара, первое — относится к сущностям Commerce, у которых собственно есть поля с ценой и другой спец-информацией, второе — к сущностям друпала и скорее представляет контекст отображения товара, третье — вообще таксономия. И если последнее вообще работа менеджеров, то первые два, как вы и сказали, решается «фичами». Сейчас фичи экспортируют многое, но некоторых вещей, согласен, все же иногда не хватает. Правда у фич изначально была другая идеология, это не инструмент деплоя, а мини-приложения, поэтому они и представляют собой отдельные модули.
                  С проблемой деплоя друпал-сайта согласен, но ИМХО, это проблема не настолько серьезная, чтобы из-за нее отказываться от друпала. К тому же сейчас в разработке есть несколько перспективных модулей для деплоя, можно надеяться, у них получится хорошо сынтегрироваться с drush'ем.
                • 0
                  У Drupal с деплойментом, как и со многим другим, все замечательно.

                  Большинство разработчиков использует Git, чтобы синхронизировать файлы между средами (dev -> staging -> prod).
                  Для синхронизации баз данных можно использовать сторонние инструменты, например Drush или SQLyog.
                  Известные Drupal хостинги Acquia Cloud и Pantheon позволяют просто перетащить мышкой одну среду на другую через панель управления, и среды тут же синхронизируются.

                  Несколько способов синхронизации сред:
                  1. Сегодня многое между средами можно перенести с помощью фич (Features)
                  2. Для того, на что Features не хватает, можно использовать hook_update из API Drupal либо написать расширение для модуля Features
                  3. Drush с параметрами rsync и sql-sync тоже неплохо справляется
                  4. Модуль Deploy позволит копирвать сущьности Drupal прямо из админки одной из сред, используя веб-сервисы.
                  5. Некоторые вещи можно экспортировать/импортировть как текст руками, например Views.

                  В Drupal 8 конфигурация будет храниться в YAML формате в файлах. Кроме того, будет доступен интерфейс для более простой миграции конфигурации между средами.

                  В итоге, хочется сказать, что о всех недостатках Drupal известно, и по ним ведется серьезная работа, недостатки закрываются от версии к версии.
                  Вы можете использовать мощьный «низкоуровневый» фреймворк, но чтобы написать хоть сколько нибудь похожую CMS вам потребуются годы.
                  Решать вам.
                  • +1
                    Проблема в том, что Drupal хранит конфигурацию в БД, и при развитии существующего сайта у вас возникает две версии: одна в продакшене, с новым контентом, и другая в девелопменте, с новыми фичами.

                    Нельзя просто перенести базу из девелопмента в продакшен. Вы потеряете пользовательский контент. Деплоить новые фичи путем копирования базы Drush'ем — это розовая мечта.

                    Базы потребуется мерджить. Но нельзя просто взять какие-то таблицы из продакшена, а какие-то из девелопмента. Это поломает сайт.

                    Смерджить базы, ничего не сломав, — задача нетривиальная и до сих пор нерешенная. Как говорится, если от болезни существует множество разных способов лечения, значит, она неизлечима. Я допускаю, что гиганты вроде Acquia имеют проприетарные решения, которые работают, но они ими с сообществом не поделятся, потому что это их конкурентное преимущество.

                    Когда я сидел на Drupal 6, я для этой задачи более или менее успешно использовал dbscripts. Проект умер, к большому сожалению, но вполне закономерно. Умер и Deploy, который вы рекомендуете, причем даже раньше, чем dbscripts, хотя успел родить сырую альфу для Drupal 7, которой я бы не рискнул пользоваться. Подобных проектов я видел много, но ни один не дорос до рабочего релиза, так что я считаю этот путь тупиковым. Уверен, со мной согласится любой разработчик, знающий значение термина «миграция».

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

                    Про идею импорта фич руками я промолчу.

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

                    Вы можете использовать мощьный «низкоуровневый» фреймворк, но чтобы написать хоть сколько нибудь похожую CMS вам потребуются годы.

                    Чтобы создать подобный Drupal конструктор — да. Чтобы создать проект, аналогичный по функционалу сайту, собранному на Drupal, потребуется столько же или меньше времени, чем на Drupal (если, конечно, речь идет о более или менее сложных сайтах вроде сабжа, а не сайтах-визитках с самым типовым функционалом). При этом поддержка и развитие такого проекта будут гораздо проще и эффективнее, чем на Drupal.
                    • 0
                      Features — тоже не выход, потому что вы никогда не сможете нормально задеплоить с их помощью фичи реального сайта. Половина модулей не поддерживает Features или поддерживает криво или не полностью.

                      Вы какие то странные вещи расказываете про Features. Можете назвать хотя бы несколько модулей из этой половины?
                      • 0
                        Это ваше единственное возражение по моему комменту? :)

                        Хотел в ответ на ваш вопрос дать ссылку на поиск по открытым Issues всех модулей, содержащим «features support» в заголовке, однако Drupal.org от этого падает в пресловутый WSOD.
                        • 0
                          Споры не конструктивны. Факты решают.
                          Работаю с фичами почти на всех проектах и встречаю максимум один неприятный момент с переводами, и то потому, что я даже не искал по нему решений.
                        • 0
                          Это ваше единственное возражение по моему комменту? :)
                          Это не возражение. Просто интересно стало. На стольких разных проектах делали деплой фичами и не знали, что половина модулей их не поддерживает. У Features если другие проблемы, но вы ни одну их них не назвали.
                    • 0
                      Но я уже достаточно нахлебался проблем с Drupal, чтобы потерять всякий энтузиазм и интерес.

                      По всей видимости, интерес к Drupal у вас все же остался.

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

                      • 0
                        Мой тезис был в том, что Drupal — это самая функциональная и гибкая CMS в мире, причем вся гибкость доступна в GUI, без написания строчки кода (впрочем, чтобы ей в полной мере воспользоваться, нужно изрядно поднатореть во владении Linux).

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

                        Drupal позиционирует себя как CMF, однако в этой роли это полный шлак. Сами авторы в этом расписались, приняв решение мигрировать на Symfony.

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

                        Люди, которые посвящают свою жизнь разработке на Drupal, словно надевают шоры, закрываясь от современных практик и методик вэб-разработки.
                        • 0
                          Сами авторы в этом расписались, приняв решение мигрировать на Symfony.


                          Я уважаю ваше мнение, но не могу понять эти выкрики, не подкрепленные фактами. Ссылку в студию.
                            • 0
                              Drupal позиционирует себя как CMF, однако в этой роли это полный шлак. Сами авторы в этом расписались, приняв решение мигрировать на Symfony.
                              А как по английски будет «Друпал полный шлак»? Лень всю статью читать. )
                              • 0
                                А как по английски будет «Друпал полный шлак»? Лень всю статью читать. )

                                Я лучше приведу вам кое-что по-русски:

                                расписа́ться

                                2. перен. своими поступками, поведением с полной очевидностью обнаружить, подтвердить что-либо в отношении себя
                                • 0
                                  Вот кстати список проектов которые «расписались».
                                  symfony.com/projects
                                  • 0
                                    Построить проект на фреймворке и сделать принципиальный слом парадигмы, радикальное изменение архитектуры — это совсем разные вещи.

                                    Не думаю, что хоть один из проектов в этом списке, за исключением самого Drupal, так поступал на своем жизненном пути.
                            • 0
                              Спасибо за ссылку, специально прочел статью еще раз. Так и не нашел информации о том, что интеграция (не «миграция»!) с некоторыми компонентами Symfony2 — это признак того, что, как CMF, Drupal — «это полный шлак».
                              Когда-то также в Drupal интегрировали jQuery. А теперь в 8-ку войдет еще несколько либ из Zend Framework, Backbone и многое другое.
                              Просто время требует изменений и проще объединить усилия, чем изобретать свои велосипеды с нуля.
                              • 0
                                Drupal много (очень много, по меркам компьютерных технологий) развивал собственную архитектуру. Эта архитектура себя изжила, завела сообщество в тупик. Дрис по ссылке называет некоторые проблемы, правда, далеко не все и не в таких красках, как это делают люди, нахлебавшиеся Drupal по горло.

                                По этой причине, авторы Drupal приняли волевое решение пойти радикально другим путем. У индейцев Дакота есть такая поговорка: «Если ты понял, что едешь на мертвой лошади, лучшей тактикой будет слезть с нее». Вот это как раз тот случай. У Дриса сотоварищи хватило духу слезть с мертвой лошади архитектуры Drupal.

                                Заметьте, я ничего не говорю о том, что получится из сборной солянки Symfony, Zend, Backbone и наследия Drupal. Очень хочется посмеяться над этим в духе «Можно из буханки хлеба, китайских палочек и колпачков от зубной пасты сделать троллейбус. Но зачем?» Но не буду, сначала посмотрим, что у них получится.
                              • 0
                                интеграция (не «миграция»!) с некоторыми компонентами Symfony2


                                Не знаю как вы, а я слово «миграция» в комментариях к этой статье употреблял только в этом значении.
                                • 0
                                  Ваши слова?!:
                                  Сами авторы в этом расписались, приняв решение мигрировать на Symfony.


                                  Да успокойтесь вы, я с вами не пытаюсь спорить. Что вы хотите тут всем доказать? Оправдать свой уход от Drupal? Так вас никто не судит, это ваша жизнь, ваше решение. Я его уважаю.
                                  • 0
                                    Ваши слова?!:

                                    Виноват.
                    • 0
                      Только ждать Drupal 8, на который вы не сможете смигрировать ни один ваш сайт.
                      Глупый вопрос. А почему не сможем? )
                      • 0
                        Давайте пойдем от обратного. Когда выйдет Drupal 8, вы напишете статью на Хабр о том, как смигрировали на него один из ваших флагманских проектов на Drupal 7 или 6?
                        • 0
                          А что там такого страшного то? Прям интрига какая то. )
                          • 0
                            Страшно то, что одна половина модулей вообще недоступна для новой версии Drupal, а другая, которая доступна, не имеет (или имеет неполноценные) инструменты миграции.

                            В результате проще переделать сайт с нуля на новой версии Drupal, чем мигрировать существующий. А еще проще держать его на той версии, на которой он сделан (к примеру, Флибуста с Либрусеком закономерно сидят на шестой версии).

                            Так было с 5 -> 6 и с 6 -> 7, и движение D7CX никак делу не помогло. Я не верю, что с 7 -> 8 ситуация изменится в лучшую сторону, с учетом столь кардинальных переработок.
                            • 0
                              Вы пробовали мигрировать мажорные версии других CMS? Вероятно, это тоже не легко и быстро.
                              Перестаньте сравнивать муху с слоном и низкоуровневый фреймворк с CMS.
                              • 0
                                Я сравниваю не с CMS, а CMF, иначе разговора бы не было.
                            • 0
                              А ну это не страшно. Я думал будут проблемы с миграцией данных. Конечно, нет смысла переводить сайт на новую мажорную версию, если не планируется координально менять функционал. По поводу D7CX, так и ведь никто не заставляет делать upgrade сразу как только появится релиз. После выхода 7-ки многие студии еще целый год делали сайты на 6-ке, что бы не тратить время на исправление багов в сырых модулях или на самостоятельное портирование их. Потом плавно перешли на D7. Так сказать на готовенькое. )
    • +1
      Работал с друпалом, сейчас работаю с рельсами. Не вижу ничего ужасного ни в том, ни в другом, у каждого свои задачи. Быстро сделать мощный рабочий сайт на друпале значительно проще, чем на любом из фреймворков. Что может понятнее, чем реализовать основной функционал на вьюсе и на других стандартных модулях, а потом, при необходимости, «врезаться» на любой этап билда страницы своим модулем? Я уж не говорю о таких вещах как кастомные поля для чего угодно, внятной документации по API, том же кэшировании или о готовых модулях для интеграции с внешними сервисами типа Apache Solr.
      Фреймворки же, позволяют значительно проще решать простой, но ооочень нестандартный функционал, с учетом того что стандартный сложный функционал не понадобится вообще. Rails мне в этом плане очень нравится, кода мало, сам он красивый и аккуратный.
      По вопросу метафоры об автобусе и личном авто… Выступаю за развитие общественного транспорта, хватит атмосферу засорять=) Легковой транспорт только для спецслужб!
    • +1
      > Другая причина — в отсутствии внятного цикла development -> staging -> production. Развитие уже запущенного сайта — лютая морока.

      Если вы его для себя не придумали, его и нет.
      Если у вас есть конкретные вопросы по тому, как правильно переносить конкретные изменения с дева на прод, давайте обсудим.
      По моему опыту, структура контента, разделы, страницы, панели, вьюхи, даже контент — всё отлично переносится.
      Если с чем-то возникают проблемы, мы их оперативно решаем.
      Основная проблема — люди, которые не всегда делают так, как следует. Но тут никакой Друпал не поможет.

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

      node_load($nid, $nid) — вот что бывает у тех, кому достаточно пары выходных, извините
      • 0
        Про проблемы с циклом разработки я более подробно написал тут.

        Если вы знаете элегантное решение этой проблемы, будьте добры, опишите кратко в ответе на тот коммент, а потом опубликуйте на Хабре статью об этом.

        Про node_load не понял.
        • 0
          второй параметр — номер ревизии
          он имеет смысл только тогда, когда ревизии появляются
          но в этом случае id ревизии уже не совпадает с id ноды, ничего не будет загружено
    • 0
      Вы тут столько много написали, вставлю свои две копейки. Отсутствие внятного цикла как вы утверждаете dev -> staging -> production давно уже решенная проблема, на таких профессиональных хостингах как Acquia, Blackmesh, Pantheon, всю «мороку» свели до нажатия двух — трех кнопок.

      Вы пишете что не понимаете людей которые упорно сидят на друпал? Забавно, наверное в таких компаниях как Time сидят полные дибилы :). Обьясню популярно — большой компании наплевать на чем написанна их publishing system, большая компания хочет чтоб цена разработки была минимальной при максимальной отдаче. На сегодняшний день, Drupal в смыесле cost-to-benefit ratio выигрывает у всех вами перечеислиных связок.

      Единственное в чем могу с вами согласится так это в том что это автобус, ездяший по одному маршруту. Друпал решает вполне конкретный, ограниченный набор задач.
      И деийствительно, если вам надо решить задачу под которую друпал не заточен, то вам придется поискать инструмент который подходит под вашу задачу. Вот и все.
      • 0
        Отсутствие внятного цикла как вы утверждаете dev -> staging -> production давно уже решенная проблема, на таких профессиональных хостингах как Acquia, Blackmesh, Pantheon, всю «мороку» свели до нажатия двух — трех кнопок.

        На это я уже отвечал.

        Забавно, наверное в таких компаниях как Time сидят полные дибилы :). Обьясню популярно — большой компании наплевать на чем написанна их publishing system, большая компания хочет чтоб цена разработки была минимальной при максимальной отдаче.

        Во-первых, Time.com сделан на Wordpress. Во-вторых, «такие компании как Time» не разрабатывают сайты самостоятельно. Они обращаются к другим компаниям, вэб-разработчикам.

        А вот о чем думают эти компании-разработчики — как раз вопрос.

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

        Я не считаю людей, выбирающих Drupal, дебилами, но не понимаю, как можно добровольно на это идти.
  • 0
    Кстати, хороший прирост к производительности даёт перенос полей в одну, но СВОЮ таблицу.
    Любые поля прекрасно интегрируются с вьюсами на ура.
    PS. Писал про это тут: habrahabr.ru/sandbox/74002
    • 0
      Пытались настроить выборку через промежуточную таблицу — через модуль shadow. Там используется похожая схема. Однако не нашли, как добавить в таблицу больше трех полей.
      А в целом — да, это неплохой вариант, мы о нем всерьез задумывались.
      • 0
        drupal.org/project/pbs не пробовали? Синтетика синтетикой, а у вас и количество полей и контент.
        Интересны результаты
    • 0
      Да, спасибо за ссылку на статью — весьма полезно.
  • +2
    Не лучше ли для сайта магазина использовать e-commerce движки? :)
    • 0
      Наверное лучше :)
    • +2
      drupal commerce довольно крупный набор модулей для электронной коммерции, покрывающий почти все требования которые могут возникнуть у компании заказывающей интернет-магазин. Идеология drupal и глубокая интеграция в него, делает его невероятно гибким инструментом. Такой гибкости в e-commerce движках не встречал.
      • 0
        Открытие страницы за 3 минуты — куда уж гибче!
        • +4
          Это говорит только о том, что кто-то что-то сделал не так. Не должно быть такого.
  • +3
    Как по мне то странно смотреть SQL запросы в самом конце… кэширование это конечно хорошо, но не проще сразу посмотреть Explain SQL запроса и оптимизировать его. Или это в Drupal считается плохим тоном? Я просто его ни когда не использовал.
  • +1
    в том числе непонятный deleted, который, по нашему опыту, всегда равен нулю

    Как вы вообще работаете с Drupal???!!! Читайте FieldApi, господа! А если у вас, неопытный менеджер возьмет и удалит одно из полей???
    Да, Друпал сложный в изучении, но поэтому прежде чем с ним начать работать эффективно, нужно очень много всего изучить, очень много.
    Еще есть бандлы.
    • 0
      Для менеджеров полезно создать отдельную роль, у которой не будет таких прав. Ну и field UI на продакшене лучше выключить. Кстати, тоже интересно каким образом deleted повлиял на скорость выполнения запроса.
      • 0
        Кстати, тоже интересно каким образом deleted повлиял на скорость выполнения запроса.

        Проверьте, есть ли индекс у поля в таблицах
  • 0
    За статью спасибо! Наверное такие материалы и переубеждают меня начать изучать друпал. Ни в коем случае не осуждаю ваш выбор, просто сам разрабатываю на yii где можно легко собрать и магазин и блог и сайт и что угодно из готовых extension но периодически что-то клинит и хочется начать изучать друпал или джумалу. Но читаю такие материалы и успокаиваюсь )))
  • +6
    Специально залогинился, чтобы плюсануть и рассказать как это делали мы в своём проекте.

    Поля в нодах — это очень медленно, потому что ноды — для контента. Вам нужно было использовать entity. Своя entity пишется за 1-2 часа. Преимущества:
    • все данные в одной таблице, что исключает JOINы, которые, как известно, очень медленные.
    • Интеграция с views, token, rules и пр. из коробки.
    • При желании можно выводить свои кастомные таблицы со сложными фильтрами, если views не устраивает.


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

    Мой совет — советуйтесь с друпалерами. Есть куча друпал-скайп-чатов, где можно задать вопросы и не изобретать велосипед.
    Обращайтесь!

    Всем читать drupal.org/node/2034119, чтобы подобных грустных статей было меньше.

    P.S. Да и про поиск выше — верно написали. Используйте ApacheSolr или аналоги и будет вам счастье. Стандартный поиск очень простой и для сложных вещей не годится.
  • +4
    Тут поддержу Влада Савицкого, Вы решили сделать анитипатерн магазина и я счастлив, что у Вас получилось.

    1. Хорошо, что не стали с нуля писать свою CMS, а взяли Drupal Commerce — проект в который вложено 15 млн. $ с кучей модулей из коробки и огромной россыпью в репозитарии. Плохо, что скорее всего вы половину модулей не выключили (если они Вам не нужны), не взяли более лёгкий дистрибутив Drupalife Store.
    2. Если пользуете Российский хостинг, то вторые грабли тормознутость HDD, DigitalOcean или подобный хостинг с SSD это ускорение на 1000% (модулей много читаются они долго).
    3. PHP 5.5 c OPcach именно только так и никаких других акселераторов — прирост скорости в несколько раз в отличие от голого PHP 5.3 (а если он с APC то там акселерация начинает борется с недостатком памяти сервера — но так уж работает именно APC).
    4. SOLR — отказ от него вторые крупные грабли так как он именно для этого предназначен. После этого следует что Вы строите свой HighLoad.
    5. Своя entity — всё в одной таблице, что исключает JOINы (внимание нужно только для HighLoad и только когда без этого нельзя обойтись). Третьи грабли на которые Вы наступили. Но не нужно писать entity для каждого материала, только для тех, чьи поля постоянно используете. У магазина — поиск это обычно до 70% просмотренных страниц, у тематических сайтов обратное.
    6. Есть модуль Database logging — если не всё хорошо с верстальщиками и т.п. может генерировать большой объём лога об ошибках в базу данных, база от этого тоже начинает тормозить переваривая большой insert перед показом каждой страницы. Поэтому нужно или исправить все ошибки, что падают в лог или отключить модуль. Правда об подозрительных дествиях на сайте Вы перестаёте быть настолько осведомлены после отключения модуля.
    7. Ладно раз используете поля для тяжёлых выборок, то если не используете ревизии нод, то поставьте Field SQL norevisions — пусть база будет меньше, а диску легче (внимание нужно только для HighLoad и только когда без этого нельзя обойтись).
    8. Entity cache + Memcache API and Integration или Redis и пусть Ваш кэш материалов живёт в памяти сервера а не на диске. А для магазинов ещё и commerce_entitycache обязателен.
    9. Подключение модуля memcached для кэша всего остального в памяти это правильно.
    10. Про cache_form хорошо Spleshka написал в статье: «Система кэширования Drupal 7. Часть первая: сегменты кэша», там всё от и до от того как и заканчивая зачем.
    11. Просматривайте чего генерит views (у него на странице со списком представлений есть вкладка настройка и там галочка — показывать SQL), иногда то, что накидают через UI (например 500 связанных полей (реальный пример)) генерит не реальный JOIN.

    Самое главное — спрашивайте. Про оптимизацию Drupal 6 я ешё в 2009 году писал, про оптимизацию Drupal 7 Spleshka (например: drupalace.ru/lesson/otdayom-kesh-anonimov-bez-podnyatiya-bekenda-drupal-7-nginx-memcached). К его статьям мне и добавить то нечего. Если есть вопросы по HighLoad, я всегда отвечу тут: www.drupal.ru/username/irbis
    • 0
      а если он с APC то там акселерация начинает борется с недостатком памяти сервера — но так уж работает именно APC
      Не понял.

      ЗЫ У нас PHP 5.3 + APC + соответствующий модуль для друпала — вроде, работает. Для выдачи 99 процентов материалов из кэша пришлось выделить 800 МБ — и стало хорошо.
      • 0
        Если модулей очень много, то с APC есть тарбл что опкод страницы начинает подходить под 150 мегабайт, который долго грузится с HDD в память, особенно если это многострадальный HDD замученный раздачей картинок заодно. Это очень много, ещё на 5.3 стал использовать вместо APC — eAccelerator. PHP 5.5 c OPcach и быстрее и памяти меньше ест.
  • +1
    У меня вопрос, касательно сути того, что вы делаете, а не выбранного инструмента.

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

    Выбор сначала по ключевым 3-м параметрам (Цена, Тип устройства, тип:
    market.yandex.ru/catalogmodels.xml?CAT_ID=1016608&hid=138608
    удовлетворяет 80% людей, которые ищут или приобретают принтер.

    Если мало — Расширенный поиск
    market.yandex.ru/guru.xml?CMD=-RR%3D9%2C0%2C0%2C0-VIS%3D8070-CAT_ID%3D1016608-EXC%3D1-PG%3D10&hid=138608
    И бренд и формат и WiFi
    удовлетворяет еще 14% твоих пользователей

    Мало? Все параметры
    market.yandex.ru/guru.xml?CMD=-RR%3D9%2C0%2C0%2C0-VIS%3D8070-CAT_ID%3D1016608-EXF%3D1-EXC%3D1-PG%3D10&hid=138608
    оставшиеся 6% людей (выбирающих принтер по ресурсу девелопера, или кто ищет обязательно PC FAX) тоже удовлетворены.

    Экономия на ресурсах просто ошеломительная.

    Вы еще сделайте возможность выборки по базе только при условии 100% заполнения всех полей. Чтобы ваш пользователь потратил кучу своего времени и вышел спецом по существующим принтерам :)
  • 0
    Спасибо за то, что поделились своим опытом! Приезжаейте на DrupalCamp в Питер в июне!
  • 0
    А все поля с характеристиками принтера вы хранили в commerce product или в node display? Есть ли существенная разница )? И если есть, то где правильно хранить поля-характеристики товара?

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