12 февраля 2018 в 13:32
Доброго дня, специалисты по друпал!
2 года назад разработали сайт https://domotehnika.by/ на друпал 7.
Все что нужно заказчику - наши разработчики делаю хорошо: доработки, импорты - экспорты, все фишки , которые требуются - реализовывают.
Но , постоянно боремся со скоростью .. разработчик сетовал на хостинг .. съехали с белорусского на drupalhosting.ru .. особо ничего не поменялось. яндекс "ругается" на долгое время ответа сервера .. более 3000мс.
Это и визуально заметно(
Посещаемость сайта растет (2500-3000 уников в сутки) , тупняк тоже растет ((
Мы готовы вкладывать деньги - вопрос куда ? в сервера или в новых разработчиков?
Нужно чтобы сайт летал! Конкуренты просто в отрыве гигантском от 100-800мс , переходы по страницам мгновенные..
Наши разработчики говорят - нужен выделенный сервер и варниш на нем..
Помогите сторонним советом - кто может проанализировать ситуацию, сделать возмездный или безвозмездный аудит. Все переделать или чтото донастроить.
Комментарии
В аудит бы вам вложиться сначала.
А далее в зависимости от бизнес-процессов, может и буст + аяксовая корзина спасут положение, а может надо говнокод чистить, если он есть
Не глядя на ваш проект изнутри, и не видя данных мониторинга по нагрузке, какой-либо реальный совет в какую сторону вам нужно будет двигаться, просто невозможно.
Но вот одно наблюдение:
Практически всегда, когда разговор заходит о varnish, это говорит о том, что разработчики не понимают, как надо решать проблемы с производительностью, или хотя бы как их найти, и думают, что он станет "таблеткой для решения всех проблем", а в реальности этого, конечно, не происходит - это в 90% случаев просто не подходящий инструмент, а в остальных 10% плохо работающий...
Я бы сказал, что варниш, шардинг и горизонтальное масштабирование являются словами маркерами.
Последние два бывают нужны, как раз... А вот память которую скушает varnish всегда можно применить более разумным образом.
Причем скушает он её для юзеров без сессии.
Как только юзер положил товар в корзину - всё, стал ходить мимо варниша.
Деньгипамять на ветер.А как же хваленный ESI варнишевский?
Его еще надо суметь приготовить.
Кеш фрагментов всегда разумнее делать на уровне приложения, где можно правильно проводить инвалидацию и регенерацию кеша, а не где-то снаружи, где это можно делать только по жёстким ttl...
К тому же, если и использовать ESI, то приложение должно проектироваться изначально с учётом этого. В случае Drupal это и близко не так, зато есть полно разных вполне рабочих механизмов кеширования внутри.
кто может провести аудит - пишите пожалуйста в ЛС , что нужно (какие доступы) , цену , срок выполнения .
спасибо!
Сильно сомневаюсь, что вас выделенный сервер и варниш спасут. Явно, переделывать.
Задачи 2:
- Аудит по серверу + предложения
- Аудит по коду сайта + предложения
доброго дня! если вы готовы выполнить данные задачи - напишите стоимость и сроки
- По хосту я не спец, но есть добрые люди
- По Сайту могу, пишите в личку
И как результат аудитов?
Кто-то помог из заявившихся?
хоть я половины не понял ваших слов , но пока я спрашивал - наши разработчики настроили варниш (хоть здесь и писали что это не поможет , и работа с варниш говорит о их некомпетентности) и все стало работать гораздо веселее..
есть еще вопросы, но божатся все закроют
всем большое спасибо за участие в обсуждении) все предложения, ваши слова: ко всему присматриваемся, вникаем
Хороший теперь совет - это навести порядок с фронт-эндом. Проблема в том, что на каждом товаре висит по 2 флага (избранное и сравнение) и их вероятно придётся переделать на кастом или как-то оптимизировать.
Собственно, проблема-то остаётся. Непрогретый кэш - грузится долго. Применяются фильтры - грузится долго. Тут надо вникать почему долго формируется страница, а потом уже экспериментировать с кэшем.
Простой пример:
https://domotehnika.by/blendery/redmond?f[0]=field_blender_power%3A600&f...
X-Varnish-Cache MISS
X-Varnish-Cacheable YES
TTFB: 2341 ms
И это на каждое изменение фильтра, пока кто-то не переберёт все комбинации. Тут проблема в архитектуре.
Проблема практически всегда в архитектуре. И всякий стартап сталкивается с подобными проблемами.
Варнишь можно прогревать (если нужно), сие не есть большая проблема.
Вопрос в том, что конкретно уважаемые доны предлагают делать сейчас? Думаю, что вариант "переписать с нуля с правильной архитектурой" не рассматривается, самолёт уже летит, нужно чинить этот.
И этот прогретый кеш будет использоваться на доли процента, кушая массу памяти при этом? И это будет маскировка проблемы, а не решение...
На самом деле, надо взять профайлер, найти причину долгого построения страниц, и исправить.
А память отдать туда, где она будет действительно полезна, например, тому же mysql. Или для кеширования entities в memcached, или ещё для чего-нибудь полезного.
Да там сайт ужа так разросся, что даже профилирование не показывает принципиально узких мест. Везде по капельки, а вылазит 3 секунды на загрузку.
Тогда надо ставить вопрос об упрощении страниц, вероятно.
Но на деле, не бывает практически никогда так, чтобы при 3 секундах загрузки не было бы проблем, которые надо было бы решить... А то, что нет в calltrace какого-то одного блока выполняющегося очень долго, в общем-то не показатель, надо смотреть самые вызываемые, может быть, что-то вызывается слишком много раз просто.
Есть много вариантов улучшения. Например, флаги. На листингах товаров на каждом товаре висит по 2 флага, я об этом писал выше.
Флаги - потому что нужно было быстро запустить магазин накануне 2016 года. Никто тогда про проблему быстродействия не думал. Более того, даже заказчик не думал. Теперь флаги есть, их нужно перебрать.
И таких проблемок, на самом деле, сотня.