Comments 51
Сразу видно, автор не знаком с Drupal.
Стандартного редактора в друпале не было вообще. Он появился только с 8 версией. В тоже время для семерки есть сторонние модули CKEditor и Wysiwyg, которые позволяют подключать 11 различных редакторов.
Стандартный редактор имел очень сильно урезанный функционал и выглядел как дитя 90-х, особенно на фоне встроенного редактора Wordpress.
Стандартного редактора в друпале не было вообще. Он появился только с 8 версией. В тоже время для семерки есть сторонние модули CKEditor и Wysiwyg, которые позволяют подключать 11 различных редакторов.
Да, правда, вспомнил. Я давно уже не работал с Drupal 7 и всегда мой первый шаг был установкой www.drupal.org/project/wysiwyg, его практически все и использовали вот я его стандартным и обозвал.
Обилие едиторов поддерживаемых Wysiwyg было скорее проблемой чем фишкой. Лучше бы сделали один но красиво ( как теперь в 8-ке )
Обилие едиторов поддерживаемых Wysiwyg было скорее проблемой чем фишкой. Лучше бы сделали один но красиво ( как теперь в 8-ке )
Но сделать подобное Wordpress-у ОЧЕНЬ нетривиально. Как минимум у меня путем только конфигурирования готовых модулей не вышло.
Сам являюсь бэкенд разработчиком под Друпал, но для своих контент проектов выбрал Wordpress, только ради редактора, в котором людям легче работать. (Хотя бэкенд часть ВП приводит меня несколько в ужас конечно и расширять функционал на него сильно сложнее\неудобнее)
В идеале конечно было бы лучше допилить все на друпал, но просто нет времени и сил на это :\.
Сам являюсь бэкенд разработчиком под Друпал, но для своих контент проектов выбрал Wordpress, только ради редактора, в котором людям легче работать. (Хотя бэкенд часть ВП приводит меня несколько в ужас конечно и расширять функционал на него сильно сложнее\неудобнее)
В идеале конечно было бы лучше допилить все на друпал, но просто нет времени и сил на это :\.
Мда… если производительность восьмерки действительно в три раза хуже семерки, то это полная *опа. Из моей практики, значительная часть времени при разработке Друпал-проекта уходила не на реализацию фич, а на то, чтобы продумать стратегию того как-бы похитрее закешировать данные, а потом вовремя инвалидировать кеш. С восьмеркой, видимо, это время только возрастет.
функциональному программированию на Wordpressне путайте функциональное и процедурное программирование. Функциональным программированием в Wordpress и не пахнет.
Про реализацию мультиязычности бы поподробнее
UFO just landed and posted this here
UFO just landed and posted this here
Я не призываю минусовать автора, но в текущем варианте статья просто вброс. Автор не компетентен по производительности, в каждом RC drupal производилась доработка производительности и RC2 от VS beta отличаетсяя по производительности в десятки раз.
Уже в RC1 Drupal 8 alexrayu.com/blog/should-we-be-very-concerned-drupal-8-performance-drop производительность D7 vs D8 была ещё печальной, но уже видно насколько она быстрее вордпресса без покупных плагинов кэширования.
А в RC2 Drupal 8 www.redy.host/blog/drupal-741-vs-drupal-8-rc2-benchmarking-analysis производительность D7 vs D8 всего на 30% отличается. При этом в D8 имеется Views размером с сам D7, т.е. если в D7 поставить модули, чтоб он по функционалу был как D8 то разница производительности будет ещё меньше.
При этом D8 оптимизирован под PHP7 и на нём в разы быстрее — www.redy.host/blog/php-7rc5-released-heating-drupal-8-performance-concerns а вот PHP7 + D7 всё по печальнее — www.drupal.org/node/2454439 при этом есть модули сообщества для D7 которые нужны и годами для D7 не обновлялись (какая уж совместимость), а в D8 их аналог уже в коробке.
Уже в RC1 Drupal 8 alexrayu.com/blog/should-we-be-very-concerned-drupal-8-performance-drop производительность D7 vs D8 была ещё печальной, но уже видно насколько она быстрее вордпресса без покупных плагинов кэширования.
А в RC2 Drupal 8 www.redy.host/blog/drupal-741-vs-drupal-8-rc2-benchmarking-analysis производительность D7 vs D8 всего на 30% отличается. При этом в D8 имеется Views размером с сам D7, т.е. если в D7 поставить модули, чтоб он по функционалу был как D8 то разница производительности будет ещё меньше.
При этом D8 оптимизирован под PHP7 и на нём в разы быстрее — www.redy.host/blog/php-7rc5-released-heating-drupal-8-performance-concerns а вот PHP7 + D7 всё по печальнее — www.drupal.org/node/2454439 при этом есть модули сообщества для D7 которые нужны и годами для D7 не обновлялись (какая уж совместимость), а в D8 их аналог уже в коробке.
Я вот выше комментом написал что буквально вчера пробовал у себя на сервере и получил почти те же результаты.
Apache2 + PHP-FPM ( PHP 7 RC 7 ) + MariaDB
Intel Xeon CPU X5650 @ 2.67GHz
Может я какой-то кеш не включил или что. Пробовал голый 8 против голого 7.
Apache2 + PHP-FPM ( PHP 7 RC 7 ) + MariaDB
Intel Xeon CPU X5650 @ 2.67GHz
Может я какой-то кеш не включил или что. Пробовал голый 8 против голого 7.
Тут нужно смотреть, возможно что то просто мешает хорошим тестам. Я бы порекомендовал попробовать NGINX + PHP-FPM 5.6 c opcache и MySQL или аналог версии > 5.6. И при тестах мониторить I/O. Бывает проблема с тем что Apache2.2, а не Apache2.4 стоит и он притормаживает. Бывает база начинает тормозить при большой нагрузке. В таком случае может показаться, что виноват Drupal, а тормоза из-за оборудования, при повторении тестов на другом оборудовании показатели могут быть лучше.
В одной из версий RC D8 было внедрено и включено по умолчанию динамичное кэширование страниц которое довольно хорошо добавили скорости. Подробнее об этом — wimleers.com/blog/drupal-8-page-caching-enabled-by-default. Возможно Вы обновили файлы не обновляя базу данных и при тестировании не включили кэширование?
В одной из версий RC D8 было внедрено и включено по умолчанию динамичное кэширование страниц которое довольно хорошо добавили скорости. Подробнее об этом — wimleers.com/blog/drupal-8-page-caching-enabled-by-default. Возможно Вы обновили файлы не обновляя базу данных и при тестировании не включили кэширование?
Ну у меня на этой связке куча сайтов крутится ( порядка 30-ти), так что не думаю что проблема в апаче или базе. Потом на DigitalOcean закину демку для всех если время будет. Там и попробуем =)
Я Вас понимаю, но это не значит что настройки оптимальные и тормозит именно Drupal. В поддержке находится инстанс с PHP 4, на нём Drupal 5 работает а Drupal 7 нет — это не значит, что Drupal 7 плохой. Нужны сравнения как минимум на NGINX + PHP-FPM 5.6 c opcache и MySQL или аналог версии > 5.5. Apache может давать неплохую погрешность (особенно версии 2.2), HDD вместо SSD могут очень тормозить базу данных и поэтому нужно мониторить I/O. И в таком случае тесты превращаются в сферического коня в вакууме. А сферический конь в вакууме это плохо — обижает сообщество, особенно если Вы не являетесь его частью.
Так я же написал что у меня ПХП 7 (под какую вы говорите он уже оптимизирован ) опкеш включен, Апач 2.4, SSD тоже есть (глупо было бы ставить Ксеон и не запускать на SSD )
Но если честно тестировать надо как раз таки на стандартном shared хостинге на которых куча сайтов крутиться и Wordpress на ура работает.
Но если честно тестировать надо как раз таки на стандартном shared хостинге на которых куча сайтов крутиться и Wordpress на ура работает.
У Вас хорошие статьи по PHPixie, если у Вас будет желание написать статью про собственное тестирование Drupal8, то напишите в личные сообщения и я с технической стороны помогу как тестами на своём оборудовании, так и могу помочь рекомендациями по статье, если это Вам поможет.
Пасяб =) У меня еще лишних 20$ на DigitalOcean есть, так что можно попробовать в нескольких кофигах. Сейчас что-то попробую запустить =)
Если результат кривой будет скину код и попробуем у вас =)
Если результат кривой будет скину код и попробуем у вас =)
К нашей общей переписке с jigpuzzled подключился chilic (точнее ребята подключили меня), ссылку на его тесты (chilic-a) добавили в статью. Не совсем однозначно получается с производительностью, хорошая тема для статьи — исследования в drupal блог на Хабрахабр. Ребят, спасибо, что такие отзывчивые, приятно когда авторы вступают в диалог и вместе помогают найти истину.
после стольких лет Drupal растерял большинство пользовательской базы и вряд ли соберет ее обратно
Русских разработчиков тоже заметно поубавилось в Drupal-сфере.
Посмотрите на Хабре старые анонсы, да и вообще статьи по Drupal, минимум по 40 комментариев, а проявленного интереса много.
после стольких лет Drupal растерял большинство пользовательской базы и вряд ли соберет ее обратно
а есть цифры?
www.google.ru/trends/explore#q=drupal
www.indeed.com/jobtrends?q=drupal&l=&relative=1
www.itjobswatch.co.uk/jobs/uk/drupal.do
redcrackle.com/blog/drupal-dying
ну и в рунете пишущих про друпал осталось единицы
www.indeed.com/jobtrends?q=drupal&l=&relative=1
www.itjobswatch.co.uk/jobs/uk/drupal.do
redcrackle.com/blog/drupal-dying
ну и в рунете пишущих про друпал осталось единицы
Несколько моментов по поводу производительности Drupal 8 vs Drupal 7:
- Само сравнение не корректно. Так как в Drupal 7 отсутствует большая куча модулей которые в Drupal 8 присутствуют в ядре. Тоже самое когда то говорили про сравнение Drupal 7 vs Drupal 6.
- Drupal 8 (теоретически) должен лучше масштабироваться в следствии новой архитектуры (сервисы, ленивая загрузка кода, отсутствие module файлов, на порядок меньшее кол-во хуков) и т.д. Было бы интересно увидеть бенчмарки какого нибудь интерпрайз проекта (200+ включенных модулей) до и после миграции.
- В Drupal 8 количество включенных модулей на стреднестатистическом сайте будет меньше (теоретически). В первую очередь из-за новой системы конфигурации, котороая позволяет избавится от необходимости держать включенными features модули (на некоторых проектах их десятки).
- Новоя структура файлов (PSR4) также позволяет уменьшить количество модулей. Если на крупном Drupal 7 проекте поместить весь самодельный код в один модуль, то получится огромный module файл-портянка, который трудно поддерживать. По этой же причине крупные contributed модули реализованны ввиде кучи под модулей (например OG).
- Новое cache API. По словам разработчиков Drupal 8 может отдавать страницы для авторизованных пользователей почти с такой же скоростью как для анонимных пользователей. Так как такое кэширование требует индивидуальной настройки для каждого конкретного сайта и не работает из коробки в приведенных бенчмарках это абсолютно не учтено. Нужно отметить что новая система кэширования очень сложная (cache tags, cache contexts, cache placeholders и т.д.) и наверно многие разработчики даже не станут с ней разбиратся...
Drupal 8 is the fastest Drupal ever.Fabian Franz — Drupal core maintainer
DrupalCon Barcelona 2015: Making Drupal fly — The fastest Drupal ever is here! (слайды)
в Drupal 7 отсутствует большая куча модулей которые в Drupal 8 присутствуют в ядре
от того что они в ядре, меньше ресурсов они потреблять не стали
отсутствие module файлов, на порядок меньшее кол-во хуков
module файлы не месте, уменьшение числа хуков с лихвой перекрывает увеличение числа классов и интерфейсов
Так как такое кэширование требует индивидуальной настройки для каждого конкретного сайта и не работает из коробки в приведенных бенчмарках это абсолютно не учтено
это кэширование не требует индивидуальной настройки и работает из коробки, оно даже включено по умолчанию. см модуль Internal Dynamic Page Cache — wimleers.com/blog/drupal-8-page-caching-enabled-by-default
Сравнивать Wordpress и Drupal 8 как минимум некорректно, это тоже самое что сравнивать автобус и легковой автомобиль. Drupal целенаправленно двигается в сторону фреймворков и энтерпрайз разработки.
от того что они в ядре, меньше ресурсов они потреблять не стали
Да, но в бенчмарках голая 7-ка без этих модулей.
уменьшение числа хуков с лихвой перекрывает увеличение числа классов и интерфейсов
Это спорно.
это кэширование не требует индивидуальной настройки и работает из коробки
Потребует на реальном проекте. Только разработчик может точно знать бизнес логику и соотетственно решить как и для кого должны кэшироваться страницы, блоки, вьюхи и т.д., а так же определить в какие моменты должна происходить инвалидация кэша.
Да, но в бенчмарках голая 7-ка без этих модулей.
установка views мало что изменит
Это спорно.
всё крайне однозначно — www.drupal.ru/comment/652502#comment-652502
Хорошие скриншоты в комментарии у Gor-а который Вы привели. Функций стало больше, вызовов больше, больше тиков процессора на обработку требуется. Всё это отставание можно наверстать только кэшированием всего и вся и ещё поэлементно со сбором из частей другого кэша (как Varnish + ESI из коробки), что из коробки и было встроено в D8. Если бы такое кэширование из коробки перенести на D7 или в Backdrop CMS, то была бы хорошая замена Varnish + ESI который стоит не на всех хостингах и не все его умеют настраивать.
К вопросу о популярности: по-моему, Drupal потерял позиции из-за кастомизируемости и стремления быть Content Manage Framework, следовательно, более высокого порога входа, чем у других CMS. Я базируюсь на своём скудном опыте, но, IMHO, моя история показательна.
Как-то лет пять назад я схватил Drupal и два модуля к нему — Views и CCK, большую часть остальных выкинул за ненадобностью. Для меня, не имевшего дела с вебом, это был очень позитивный опыт: я почувствовал, что действительно управляю контентом, строю сайт под себя. Views и CCK стали для меня краеугольным камнем.
Но, изучив веб-фреймворки я понял, что переизобретаю модели. Встал вопрос: зачем мне Drupal, если всё, что мне надо, дают фрейворки, при этом я получаю сходный уровень абстракции при лучшей управляемости и понимании, как оно работает. Я для себя на этот вопрос ответил, увы, не в пользу Drupal.
Как-то лет пять назад я схватил Drupal и два модуля к нему — Views и CCK, большую часть остальных выкинул за ненадобностью. Для меня, не имевшего дела с вебом, это был очень позитивный опыт: я почувствовал, что действительно управляю контентом, строю сайт под себя. Views и CCK стали для меня краеугольным камнем.
Но, изучив веб-фреймворки я понял, что переизобретаю модели. Встал вопрос: зачем мне Drupal, если всё, что мне надо, дают фрейворки, при этом я получаю сходный уровень абстракции при лучшей управляемости и понимании, как оно работает. Я для себя на этот вопрос ответил, увы, не в пользу Drupal.
А можете поподробнее описать — на какие фреймворки перешли после Drupal? Мне не нравится, что в друпал слишком много лишнего, хотелось бы перейти в некоторых задачах на что-то более легковесное, но с удобным веб-конструктором моделей, сущностей, представлений, чтобы не в коде ковыряться-описывать все, а как в друпал — прямо в админке создал entity, поля, связи, представления страницы. Ну а результаты уже превратяться в код, который я уже причешу под себя.
Или фреймворки это как раз когда все ручками пишешь в коде, без удобного интерфейса админки?
Или фреймворки это как раз когда все ручками пишешь в коде, без удобного интерфейса админки?
А можете поподробнее описать — на какие фреймворки перешли после Drupal?
Остановился, в итоге на Django и Flask, поэтому простите, за PHP-аналоги не поясню.
с удобным веб-конструктором моделей, сущностей, представлений, чтобы не в коде ковыряться-описывать все,
Из того, что я видел — да, всё код.
а как в друпал — прямо в админке создал entity, поля, связи, представления страницы. Ну а результаты уже превратяться в код, который я уже причешу под себя.
Из того что видел — обратное, изменения в коде отражаются на админке.
Но, опять же, повторюсь, разработка для меня хобби, мой опыт скуден. Но я посмею дать совет — возьмите фреймворк на языке, который знаете, возьмите руководство (практически ко всех фреймворкам руководства хороши) и, если у Вас уже есть проект — попытайтесь переписать его на этом фрейморке; если нет — ну, обычно к фреймворку есть учебный проект.
Удачи!
Популярность потерял, потому что работает на «инженеров», а не на контент-менеджеров. Впрочем это написано в посте
Sign up to leave a comment.
Вышел Drupal 8 — критический взгляд