Проблема скорости загрузки сайта

Главные вкладки

Аватар пользователя centaur centaur 12 февраля 2018 в 13:32

Доброго дня, специалисты по друпал!

2 года назад разработали сайт https://domotehnika.by/ на друпал 7.
Все что нужно заказчику - наши разработчики делаю хорошо: доработки, импорты - экспорты, все фишки , которые требуются - реализовывают.
Но , постоянно боремся со скоростью .. разработчик сетовал на хостинг .. съехали с белорусского на drupalhosting.ru .. особо ничего не поменялось. яндекс "ругается" на долгое время ответа сервера .. более 3000мс.
Это и визуально заметно(
Посещаемость сайта растет (2500-3000 уников в сутки) , тупняк тоже растет ((

Мы готовы вкладывать деньги - вопрос куда ? в сервера или в новых разработчиков?
Нужно чтобы сайт летал! Конкуренты просто в отрыве гигантском от 100-800мс , переходы по страницам мгновенные..
Наши разработчики говорят - нужен выделенный сервер и варниш на нем..

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

Комментарии

Аватар пользователя Semantics Semantics 12 февраля 2018 в 13:35

В аудит бы вам вложиться сначала.
А далее в зависимости от бизнес-процессов, может и буст + аяксовая корзина спасут положение, а может надо говнокод чистить, если он есть

Аватар пользователя bsyomov bsyomov 12 февраля 2018 в 13:47

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

Но вот одно наблюдение:
Практически всегда, когда разговор заходит о varnish, это говорит о том, что разработчики не понимают, как надо решать проблемы с производительностью, или хотя бы как их найти, и думают, что он станет "таблеткой для решения всех проблем", а в реальности этого, конечно, не происходит - это в 90% случаев просто не подходящий инструмент, а в остальных 10% плохо работающий...

Аватар пользователя bsyomov bsyomov 12 февраля 2018 в 13:50

Последние два бывают нужны, как раз... А вот память которую скушает varnish всегда можно применить более разумным образом. Smile

Аватар пользователя Andruxa Andruxa 12 февраля 2018 в 16:27

Причем скушает он её для юзеров без сессии.
Как только юзер положил товар в корзину - всё, стал ходить мимо варниша.
Деньги память на ветер.

Аватар пользователя bsyomov bsyomov 14 февраля 2018 в 6:55

Кеш фрагментов всегда разумнее делать на уровне приложения, где можно правильно проводить инвалидацию и регенерацию кеша, а не где-то снаружи, где это можно делать только по жёстким ttl...

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

Аватар пользователя centaur centaur 12 февраля 2018 в 14:55

кто может провести аудит - пишите пожалуйста в ЛС , что нужно (какие доступы) , цену , срок выполнения .
спасибо!

Аватар пользователя centaur centaur 28 февраля 2018 в 15:42

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

Аватар пользователя Gena84 Gena84 28 февраля 2018 в 15:44

Хороший теперь совет - это навести порядок с фронт-эндом. Проблема в том, что на каждом товаре висит по 2 флага (избранное и сравнение) и их вероятно придётся переделать на кастом или как-то оптимизировать.

Аватар пользователя fairrandir fairrandir 28 февраля 2018 в 15:55
1

centaur wrote:

наши разработчики настроили варниш

fairrandir wrote:

Если проблема как раз в некэшируемом представлении - authcache не поможет. И вообще, кэш на странице каталога с фильтрами не поможет. Слишком много комбинаций фильтров, кэш лопнет, а потом его инвалидировать еще, если буковка в названии товара изменилась.

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

Простой пример:
https://domotehnika.by/blendery/redmond?f[0]=field_blender_power%3A600&f...
X-Varnish-Cache MISS
X-Varnish-Cacheable YES
TTFB: 2341 ms
И это на каждое изменение фильтра, пока кто-то не переберёт все комбинации. Тут проблема в архитектуре.

Аватар пользователя Gena84 Gena84 28 февраля 2018 в 16:03

Проблема практически всегда в архитектуре. И всякий стартап сталкивается с подобными проблемами.

Варнишь можно прогревать (если нужно), сие не есть большая проблема.

Вопрос в том, что конкретно уважаемые доны предлагают делать сейчас? Думаю, что вариант "переписать с нуля с правильной архитектурой" не рассматривается, самолёт уже летит, нужно чинить этот.

Аватар пользователя bsyomov bsyomov 28 февраля 2018 в 17:38

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

На самом деле, надо взять профайлер, найти причину долгого построения страниц, и исправить.
А память отдать туда, где она будет действительно полезна, например, тому же mysql. Или для кеширования entities в memcached, или ещё для чего-нибудь полезного.

Аватар пользователя Gena84 Gena84 28 февраля 2018 в 17:41

Да там сайт ужа так разросся, что даже профилирование не показывает принципиально узких мест. Везде по капельки, а вылазит 3 секунды на загрузку.

Аватар пользователя bsyomov bsyomov 28 февраля 2018 в 17:51

Тогда надо ставить вопрос об упрощении страниц, вероятно.
Но на деле, не бывает практически никогда так, чтобы при 3 секундах загрузки не было бы проблем, которые надо было бы решить... А то, что нет в calltrace какого-то одного блока выполняющегося очень долго, в общем-то не показатель, надо смотреть самые вызываемые, может быть, что-то вызывается слишком много раз просто.

Аватар пользователя Gena84 Gena84 28 февраля 2018 в 17:56

Есть много вариантов улучшения. Например, флаги. На листингах товаров на каждом товаре висит по 2 флага, я об этом писал выше.

Флаги - потому что нужно было быстро запустить магазин накануне 2016 года. Никто тогда про проблему быстродействия не думал. Более того, даже заказчик не думал. Теперь флаги есть, их нужно перебрать.

И таких проблемок, на самом деле, сотня.