Производительность Drupal 8?
20 августа 2017 в 17:31
Можете привести примеры,какую нагрузку "держат" проекты на базе Drupal 8?
- Блог
- Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Можете привести примеры,какую нагрузку "держат" проекты на базе Drupal 8?
Комментарии
Yes, Drupal 8 is slower than Drupal 7 - here's why
Как раз читал эту статью :)). Но живые примеры и сколько?
Drupal 8 production sites
Making Drupal 8 fly
Пишут,Drupal 8 держал на тестах 1200 клиентов (не запросов) на машине с 8GB/8CPU, далее стал сыпаться с 500ками и таймаутами. 7-ка все таки попроизводительнее на тестах себя показала.
«I feel the real performance of Drupal 7.41 is around 15%-25% better comparing to Drupal 8 RC2.»
7.41 и 8рц2, нуну.
А поподробнее?
Просто попробуй сам сравнить производительность актуальных версий.
стандартный профиль 7-ки и 8-ки, немного контента от devel_generate
Это будет более верным, нежели слухи собирать)
Помимо "скорости", "нагрузки" работающего, также следует учесть и "удобство" разработки.
Имхо - 8 самая "удобная" из друпалов.
Да честно,блин,7-ка в плане программирования как-то проще/по-удобнее,чем 8-ка.
8-ка - Symphony,ООП итд.
Если подробнее, то этому бенчмарку никак не менее двух лет. И актуальные версии сегодня 7.56 и 8.3.7. Кроме того, за это время вышла ещё и новая версия пхп. Так что обсуждать попросту нечего.
Ну так быстрее стало или нет? - нет сейчас возможности сравнить (не на чем).
Восьмёрка сырая будет ещё года четыре. Мне нравится одно и тоже писать годами.
Один только минус у 7-ки - завязка на API. 8-ка написана на Symphony 2,если что сайт можно потом будет переписать на чистом Symphony 2.
Если сайт разовьется до степени, что пора переписывать. То думаю это не проблема и финансов хватит. А заботится об этом раньше времени смысла особого нету.
Тоже верно,проблемы нужно решать по мере поступления.
Это по меньшей мере не совсем так; используются некоторые компоненты Symphony.
Переписать в специализированное решение на том же Symphony, будет не легче чем 7, если подумать. И в том и в другом случае придётся просто делать приложение с нуля.
Я имею ввиду,порог вхождения меньше будет в этом случае.
Может сайт и работает на 8-ке быстро, но с сайтом быстрее работается на 7-ке.
http://aftamat4ik.ru/drupal-8-obzor/ - вот это жирок!
Чет дальше смысла читать нет )) Автору надо бы написать что 5.4 уже 2 года не поддерживается и не получает обновлений безопасности, http://php.net/supported-versions.php .
Жирок - да)
Наконец-то в Drupal соизволили завезти tinymce,Даже в базовом виде, всего с одним материалом, страница грузится почти 600 миллисекундДавно пора бы уже перевести движок под bootstrap или его аналоги. Но нет. Увы. Разработчикам Drupal рассказать об таком замечательном фреймворке, видимо, забыли.Чёт ржу. Чувак привык клепать ГС на покупных шаблонах на ВПшечке.
Тоже обратил внимание на tinymce, который на самом деле Ckeditor) И на другие неточности автора, который или на эмоциях писал или просто дилетант.
Куда не поверни хейтеры Друпала много. Или мы "сообщество" отстаём или все хейтеры глупцы. А среди хейтеров в основном кликальщики.
Истина куда более многогранна
8-ка на продакшене быстрее будет, это факт, за счет мощного кэширования которого в 7-ке нет и никак не добиться. В дев окружении быстрее 7-ка. но это никого волновать не должно особо.
Позволю себе немного не согласиться. Есть два идентичных сайта под рукой: на Drupal 7 и на Drupal 8. TTFB, первый экран, время до интерактивности, вот это вот всё, идентичны, и укладываются в секунду. Вопрос во времени, затраченном на то, чтобы добиться такого результата. На D8 это у меня заняло меньше времени, при том, что это мой первый сайт на 8-ке.
Так что вопрос больше в удобстве и, соответственно, скорости разработки.
Чем больше будет разрастаться проект и его гибкость, тем больше будет сливаться 7-ка и выигрывать 8-ка за счет своих cache context и tags.
Да, я и не спорю. Я хотел подчеркнуть, что можно делать и на 7-ке, и на 8-ке, но удобнее и быстрее на 8-ке.
Пока тема не переросла в флуд,предлагаю привести примеры,сколько клиентов/сек держат ваши личные проекты на 8-ке.
Вы же понимаете, что это все эти метрики достаточно расплывчаты, и зависят не только и не столько от друпала, сколько от настроек сервера? Или что нужен полностью идентичный сайт на обоих системах для сравнения, при этих тестах не учитывается что видит клиент, и вообще все эти метрики имеют хоть какое-то значение при посещалке СИЛЬНО выше средней, и зависят от специфики проекта, прямости рук и других факторов?
Конечно понимаю. Я же не требую цифры как в аптеке. Так на глаз прикинуть. Итого: версия drupal,установленные модули,параметры сервера,используется ли cdn итп;сколько тянет.
Не всё так однозначно - кеширование хороший приём, но не панацея. и не всегда применимо. И производительность без кеширования бывает весьма важна.
И даже при кешировании, надо не забывать, что кеш надо иногда и перестраивать.
Кэширование для производительности вам поможет,когда у вас более менее статический контент (больше чтений,чем записей). Википедия как пример.Или новостной сайт,где комменты внешние типа disqus итп. Попробуйте закэшировать страницу товара на 5-10 мин в онлайн-магазине,где постоянно совершаются покупки...
а что с этим не так?) Коллизия по наличию товаров эт этого никуда не денется. Ситуация когда остался 1 товар, 2 пользователя заходят на эту (незакэшированную!) страницу, долго внутри нее думают и покупают находясь на странице. Коллизия? да. Кэширование выключено. Что делать?) Вот решение этой коллизии можно применить как с выключенным, так и с включенным кэшем.
про кол-во записей в базу. Если мы говорим о магазине, то записи там - это действия типа корзины, покупок, сравнений и т.п. Так вот. Когда кол-во записей на эти действия упрутся в лимиты пары-тройки сервачков за 15-20т.р., владельцы магазина могут уже выбирать какой остров они планируют купить и им эти расходы будут незаметны.
« Что делать?) »
Повесить ajax-проверку статуса товара на кнопку добавления в корзину,емае.). При этом и кэш можно иcпользовать.Я вверху привел сферический пример возможных проблем с кэшем.
Cache context, tags и max-age в 8-ке вам в помощь. Можно спокойно сделать контекст по кол-ву товара в наличии, и внезапно, кэш будет работать корректно, или чистить кэш по тегу количества товаров. Смотря какой вариант лучше подойдет под магазин и его трафик и поведение.
А обновлять на странице, как вы и сказали, можно AJAX. В 8-ке это не проблема.
P.s. а в связке с #lazy_builder будет летать всегда, даже если кэш только начинает генерироваться.
Небольшой лайфхак/баг,иллюстрирующий работу кэша: как читать комментарии,закрытые по давности на Lenta.ru.
Идем https://lenta.ru/comments/news/2017/08/17/uzhasi_koshmari/ ==> "Комментарии к материалу закрыты в связи с истечением срока его актуальности"
А теперь открываем в Гугле cache:https://lenta.ru/comments/news/2017/08/17/uzhasi_koshmari/ и спокойно читаем. Почему это работает,думаю,понятно: комментарии подгружаются закэшированным javascript'овым виджетом сторонней системы комментариев на странице. (Непонятно,только почему на Lent'е это до сих пор непоfixено ¯ \ _ (ツ) _ / ¯ ).
Потому что Лента (как и другие сайты) к кешу гугла не имеет никакого отношения. Гугл грубо говоря это кеширует и хранит "для себя".
Там видно что на закэшированной странице грузятся комментарии аяксом.
Да, кеш скрипта, я потом посмотрел.
Но тем не менее - это уже лежит у гугла) то что он умеет это делать (в отличии от кеша яндекса) - Лента к этому отношения не имеет))
Если для них это проблема - то пусть думают как решить)
Причем тут кэш Гугла? Гугл кэширует только javascript,который подгружает комменты. Вопрос,какого художника они подгружаются,если они в статусе закрыто? Это баг.
А пример я привел,для того чтобы показать,как можно "пролететь" с кэшем на собственном сайте.
Сравнивать кеш сайта и кеш поисковой системы как-то странно.
Вы уж извините.
Цели разные, задачи разные, инвалидация тоже разная.