Вход • Регистрация

Долго грузит фильтр

  • 21 февраля
  • Добрый день, долго грузит фильтр на страницы товаров, больше товаров - больше время загрузки.
    Какие могут быть проблемы и пути их решения? На сайте будет около 100к товаров, было 50к фильтр грузил 6 секунд, сейчас загрузили пару тысяч, грузит тоже время, куда копать?
    https://svet.mebel-severik.ru/shop/podvesnye/
    • 22 февраля
    • Это только к разработчику фильтра.
      Вряд ли на форуме вам кто поможет.
  • 22 февраля
  • - отключите отложенную загрузку блока фильтра
    - Удалите индекс поиска по сайту
    - Переиндексируйте поиск по сайту и фильр - есть какие-то артефакты
    • 22 февраля
    • Дмитрий, думаю, что Степин фильтр на такие манипуляции чихал))
      • 22 февраля
      • хз... на 50к не тестил а вот на 11-12 работал и работает
        - лучше разработчика спросить, врят-ли кому будет интересно капаться и искать причину
        • 24 февраля, понедельник
        • У нас он даже на 1.5к товаров сейчас грузит медленно. Не понимаю как у вас на 10 грузит нормально, может в чем то другом дело.. Или понятие скорости у нас разное.
          Мы уже 3 месяца ищем решение, и поддержку подключали, но они сказали что проблема в нашем фильтре, он для поиска ищет по всей базе, а штатный только по запросу конкретному, но я, например, с пользовательской стороны вижу, что включив штатный он грузит те же 6 секунд..
          • 24 февраля, понедельник
          • Цитата
            Не понимаю как у вас на 10 грузит нормально, может в чем то другом дело..


            ну начнёс с этого:

            • У Вас хостинг не за 300 руб в месяц ?
            • C SSD Дисками ?


          • 24 февраля, понедельник
          • "3 месяца ищем" не равно "3 месяца назад начали искать" )

            смотрите запросы в базу, если они без индексов, то быстро не будет

      • 24 февраля, понедельник
      • Сейчас отключили этот фильтр, включили штатный Диафана, он кажется сломанный, без стилей, но время его загрузки, на глаз, тоже самое, грузит те же 6 секунд. Проблема может не в фильтре а в другом? Мы сейчас базу перелопатили и не помогло, 1500 товаров на сайте оставили, а фильтр работает как черепаха, а если поиск по нему нажать, я даже не замерял когда он там найдет отсортированный товар
        • 24 февраля, понедельник

          • Может у Вас много товаров на страницу....
          • Может у Вас не миниатюра Фото грузиться в списке товаров
          • Может у Вас фильтр ищет все подкатегории и не в текущей....
          • Может...
          • Может...
          • Может....
  • 24 февраля, понедельник
  • Создайте Проект - может кто то на платной основе поковыряется....
  • 24 февраля, понедельник
  • Характеристики участвующие в поиске - какого типа ? (Строка, Число, Список .....?)
    - Исключите "Строка" - Будет быстрей работать?
  • 24 февраля, понедельник
  • Характеристики "Строка" уже исключили, их вообще все переделали, осталось характеристик штук 50, и значения в них распределены, тоже не сотни.

    По хостингу, у нас максимальный тариф, думали в нем проблема хотя он и так задействуется на 20%, переходили на выделенку с увеличением, не помогло, вернулись на этот же "Премиум"
    • 24 февраля, понедельник
    • Скиньте в личку доступ в админку
  • 25 февраля, вторник , редакция: 25 февраля, вторник
  • стандарт, удалены все темы кастомные, включен защитный режим работы
    страница грузится за 14 секунд
    https://i.imgur.com/MKHPAa9.png

    грузится запросами вида

    Код
    SELECT p.name1 AS name, p.id FROM `diafan_shop_param_select` AS p INNER JOIN `diafan_shop_param_element` AS e ON p.param_id=e.param_id AND p.id=CAST(e.value1 as DECIMAL) INNER JOIN `diafan_shop` AS s ON e.element_id=s.id AND s.act1='1' AND s.trash='0' INNER JOIN `diafan_shop_category_rel` AS c ON c.element_id=s.id AND c.cat_id IN (104) WHERE p.param_id=957 GROUP BY p.id ORDER BY p.sort ASC


    таблица джойнится через поле e.value1 типа TEXT что прям печально
    даже если ему сменить тип на varchar и добьавить индекс, ускоряет но не особо, ну, страница грузится 6 секунд что тоже неприемлемо
    джойнить нужно по INT

    в общем с ростом таблицы shop_param_element и shop_param_select тормаза увеличиваются пропорционально

    я хз что тут сделаешь, вижу только вариант сделать индексную таблицу где будет все в одной подготовлено и работать с ней

    у кого какие еще идеи?
    • 26 февраля, среда , редакция: 26 февраля, среда
    • Из простого :
      1. Подключить кеширование в фильтре на каждую категорию. memcached и не будет отправлять запросы. Обычно формирование фильтра грузит mysql
      2. Проверить данные, возможно много хлама в таблицах
      Из интересного:
      1.Когда недавно столкнулся с такой же проблемой, то пришла такая же мысль , а что если создать индексы. В итоге фильтр формируется по индексам и выборка тоже.
      Получилось что то вроде такого...
      2. Переписать запросы формирующие фильтр
  • 28 февраля, пятница
  • Ага, мебель-северик, я его разбирал на косточки в ТП )
    Ребята, можете не гадать, не видя БД, никогда не догадаетесь, в чём там прикол )
    Цитата
    Проверить данные, возможно много хлама в таблицах
    Сергей близок )
    Ростислав, я же говорил в поддержке обо всех занозах. В частности, там какой-то умник решил в таблицу значений доп.характеристики, которые смотрит фильтр (значения выпадающего списка) засунуть какие-то свои "поисковые индексы". Там 105.000 значений выпадающего списка 🥹
    Цитата
    грузится запросами вида

    Это запросы степанового фильтра, который перелопачивает базу по несколько раз, чтобы обеспечить в фильтре всплывающие цифры у каждой характеристики в фильтре, сколько будет найдено тех или иных товаров, если искать их.
  • 03 марта, понедельник , редакция: 04 марта, вторник
  • Всем привет
    Виталий, теперь я ковыряю мебель-северик и фильтр)

    Сайт оооочень интересный в плане огромной базы товаров и характеристик! Как раз чтобы откатать и улучшить производительность и сделать оптимизацию

    У меня был один такой некогда по строительной тематике - в итоге клиент ушел с Диафана на другой движек как раз из за тормозов в списке товаров из за фильтра. Потому вопрос очень интересен

    Удалили вообще ВСЮ товарную базу и таблицы характеристик

    настроил импорт чтобы небыло логических дублей, мусторных рарактеристики и прочего
    загрузили товары

    https://i.imgur.com/uEznhLt.png с таблицей значений выпадающих все более или менее нормально

    выше писал

    Цитата
    стандарт, удалены все темы кастомные, включен защитный режим работы



    без Степанового фильтра (хотя если отключить у него дополнительный функционал в виде подсчета кол-ва товаров и вывода товаров подкатегорий - он делает идентичные запросы) - все стандартно

    все равно отрабатывает очень долго (скрины выше в сообщении)



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

    джойн по текстовому полю я бы убрал в любом случае в таком виде (если в чем-то тут не прав - обсуждаем:) )
    https://i.imgur.com/7aAfPeD.png

    сделал выше цикла подзапрос на список товаров которые находятся в текущей категории(категориях) - не стал их пихать в индексную таблицу как на скрине выше у Сергея

    сделал поле для числового значения айдишника селекта для нормального джойна по INT

    https://i.imgur.com/jvdfacI.png

    сделал выше цикла подзапрос на список характертисик которые обозначены для использования в поиске ибо зачем нам тонна других которые выводятся только в карточке товара и в поиске не учвствуют


    и в запросах на select,multiple и тп уже не тягаем shop, shop_category_rel
    а делаем element_id IN() выборка айдишников товаров выше(можно кешернуть) и param_id IN() выборка только параметров для поиска

    в numtext все тоже самое но без джойна ессно


    https://i.imgur.com/nEGLRNR.png
    (shop_param_element_search_index - дубль shop_param_element с добавленным и сгенерированным select_value_id)

    в итоге 1-1,5 секунд а не 14
    уже лучше

    если есть еще идеи или предложения/обсуждения - пишем
    • 04 марта, вторник
    • Как альтернативное решение: по окончанию процесса изменений, связанных с товаром, однократно инициировать фоновый скрипт, который создаст результирующие значения и зафиксирует их в отдельной таблице или таблицах. Соответственно, при обращении к страницам сайта будут браться уже готовые результаты. Такой вариант, на мой взгляд, еще быстрее. При этом новые таблицы можно держать не в базе данных, а, например, в Redis или подобном, что еще больше снизит нагрузку на базу данных.
      • 04 марта, вторник , редакция: 04 марта, вторник
      • ага, думаю тоже - лучшее решение, наверное в итоге так и сделаю + примерно аналогично модулю индескации поиска возможность ручной переиндексации в админке
    • 04 марта, вторник
    • Цитата
      Виталий, теперь я ковыряю мебель-северик и фильтр)

      Деньги только вперёд возьми ))
      Нам он не заплатил. Я убил по несколько часов в разные дни в течение пару недель в режиме "потом оплатим" и всё.
      Цитата
      если есть еще идеи или предложения/обсуждения - пишем
      Так что пардон, этим я помогать не буду )
      • 04 марта, вторник
      • Ох Виталий, я вас уважаю как программиста, но нужно думать прежде чем такие заявления публично делать, и грубить, где бы вы не находились.

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

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

        Я благодарен вам за то, что вы придумали и сделали для нас, надеюсь на дальнейшее взаимовыгодное сотрудничество, таких специалистов как вы, можно по пальцам пересчитать, кто так разбирается. Виталий, оставим эмоции позади, личные вопросы давайте в нашем в вами чате обсуждать. Здесь вопрос глобального характера.
        • 04 марта, вторник
        • Я извиняюсь, конечно, за некоторую несдержанность, но опирался исключительно на факты, которыми располагаю 😏 У нас с вами было несколько тикетов, несколько раз тикеты создавались как раз под оплату, и несколько раз и я намекал, и менеджер прямо говорил, что надо закрыть вопрос с оплатой проделанной работы, но все разы это как-то мягонько заминалось с Вашей стороны, создавались новые тикеты, мои рекомендации и решения опускались, и у меня создалось полное ощущение, что что-то идёт не так )
          Цитата
          строим интернет-магазин на диафане, но никто не может решить нашу проблему

          В любом случае, я считаю, что одна из главных проблем в разработке — это когда "к снаряду подходят" разные люди, и каждый не зная что зачем и почему изначально было сделано, пытается что-то наворотить сверху. Классическое письмо Дяди Федора родителям. То хвост отвалится, то усы жмут. 🤷‍♂️
          Я настолько знаю, Вам изначально вообще делали какой-то кастомный импорт товаров от десятков разнородных поставщиков из xml, xls и csv напрямую в БД. Затем сверху этого было наделана куча фильтров, поисков и разборов. А потом ещё какие-то индексации кто-то сверху на базу приписал... Тут уж лучше всё-таки определиться с кем-то, кто будет стабильно сайт вести, дать ему полный карт-бланш и доделать уже всё по уму.
          Если с Евгением eamat сработались, то это хорошо, он партнёр и разработчик опытный, всё получится )
          • 04 марта, вторник
          • Хорошо что решили, я не пытался заминать, буду писать менеджеру в разговоре вставлять эту кнопку оплаты, чтобы не было недопониманий. Буду в след раз внимательней.

            Да, работ у нас было проделано очень много... Сейчас нашу админку знаете Вы и Евгений очень хорошо, уже давно вместе работаем. Надеюсь найдем решение, плюсом тут есть ещё специалисты, готовые помочь советом.
    • 04 марта, вторник
    • Цитата
      все равно отрабатывает очень долго (скрины выше в сообщении)

      id там у строк почему шестизначные, если их всего несколько сотен? Просто нажали "Удалить" в таблице?

      Цитата
      Сайт оооочень интересный в плане огромной базы товаров и характеристик!

      База товаров там совершенно невзрачная, тысяч 60 товаров. А вот таблицы характеристик используются совершенно неразумно и неправильно. Наша вина только в том, что мы позволяем создавать характеристику с выпадающим списком и затем позволяем туда заносить по 100К значений (см скрин). Ну если у тебя характеристика "Цвет" и там не 15 типовых значений, а все сочетания радуги от #000000 до #FFFFFF с миллионами значений, то не надо задавать тип "Выпадающий список", ну сделай ты текстовую характеристику... Потом мы видим в базе вот такое, как на скрине этого сайта и потом хоть усрись, но уже двойном-тройной джойн по нескольким милионным таблицам не будут работать за 0.001 секунды. И я не говорю про интерфейс фильтра в браузере, куда в выпадалки заезжали тысячи значений, офигеть как удобно фильтровать...
    • 04 марта, вторник
    • Цитата
      И я, акцентирую, за то чтобы не кинуть камень в чейто огород а максимально улучшить

      джойн по текстовому полю я бы убрал в любом случае в таком виде (если в чем-то тут не прав - обсуждаем:) )
      https://i.imgur.com/7aAfPeD.png

      И если тоже не кидать камни в огород недобросовестных заказчиков и клиентов, а исключительно ради улучшений и справедливости ради, я на этот джойн тоже смотрел исподлобья, не совсем понимая его целесообразность, особенно в этом виде. В коробке, кстати, он чуть по-другому висел, но с каких пор и кто его туда так поставил, я не помню 🤷‍♂️ Надо будет его переделать.
      Но это не решит проблему бездумного заполнения системы черти чем в неограниченном количестве.
      • 04 марта, вторник , редакция: 04 марта, вторник
      • Виталий, а где есть дока для клиентов, которые заполняют сайт самостоятельно? Просто у меня примерно такая же ситуация. Клиент научился по одному алгоритму наполнять характеристики, и он их наполняет.

        Я нигде не видел мануалов у вас, которые объясняли бы пользователям как правильно работать с CMS. Как правильно заполнять характеристики чтобы фильтра не тормозили?

        Мне самому интересно было бы почитать, так же вопрос при импорте характеристик, как назначать им тип? и так далее.
        • 04 марта, вторник
        • Цитата
          Просто у меня примерно такая же ситуация. Клиент научился по одному алгоритму наполнять характеристики, и он их наполняет.

          По такой схеме работы заполнения проблем мы не встречали. Собственно, поэтому ничего и не документировали, т.к. не требуется.
          Тут опирались только на здравый смысл: если мы говорим про характеристику с выпадалкой типа "Цвет" или "Размер одежды", где список из адекватного количества значений. Адекватное количество = то, что руками можно забить, глазами окинуть, затем в выпадалке удобно выбрать. Откройте любой магазин, Озон, М-Видео, фильтр любых товаров, там список в какой-нибудь характеристике для подбора товаров сколько галок? Ну 20, ну 30, ну 100 максимум. Больше если, это уже неудобно для скролла даже и выбора в браузере или с телефона. Так вот технически у нас в CMS нет проблем и для нескольких сотен в принципе
          Проблемы есть, когда эти значения заносят не вручную, а напрямую в БД, недокументированно, и в выпадалке оказывается 100.000 значений. Это физически невозможно сделать, там просто виснет браузер, когда в админке грузится этот select/option1-option2-option3-option4-***-option9999999
          Соответственно, ситуация тоже получается недокументированная 🤷‍♂️
        • 05 марта, среда
        • Если с сайтом постоянно работаешь как менеджер, то все выясняется опытным путем.
          Сколько раз первоначально занесенные характеристики как строка переделывались в выпадашку... не сосчитать.

          Мануалы пиши - не пиши, читать не будут, или вряд ли поймут.
          Да и каждый сайт индивидуален, не подгонишь под каждого инструкцию.
  • 05 марта, среда , редакция: 05 марта, среда
  • Цитата
    в итоге 1-1,5 секунд а не 14
    уже лучше

    Опять же! Я и Ростиславу говорил несколько раз и Евгения внимание хочу ещё раз обратить, что если мы имеем сотни-сотни тысяч и миллионы записей в нескольких разных таблицах, то как не крути, множественные запросы в БД чисто физически не смогут исполниться за доли секунды.

    Вышеуказанные в теме запросы обрабатывают миллионы строк в цикле и 1.5 секунды - это адекватное время. Это нормально.
    И как раз на такие случаи помимо кеширования (в котором всё быстрее 1.5 секунд) у нас в CMS есть прекрасный инструмент lazy. Добавляем параметр lazy=defer в тег show_search и всё, сайт открывается за 0.2 секунды и пока пару секунд подгружаются шрифты, баннеры и прочие картинки, 1.5 секунды совершенно незаметно фоном грузится и фильтр. Визуально сайт открывается как пуля.
    Я не знаю, почему нужно из принципа сражаться , чтобы фильтр грузился в потоке основного источника html и тормозил всю страницу...
  • 05 марта, среда , редакция: 05 марта, среда
  • по оплате все ровно) работаем не первый месяц

    Виталий, shop_param_element - ничего не сделаешь - номенклатура действительно очень различна и очень различны значения характеристик и то это сократили вразы уже так как в импорте была еще тонна дублей (когда значение писалось как "220" "220в" "220вольт"/ "круг" "круглый" "окружность" и тд и тп) и продалжают заниматься этим
    а товары и характеристики только еще начинают добавляться заново в магазин) там еще куча поставщиков

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

    и да, тоже думаю 1,5 секунды вполне норм для такого "потлотна" характеристик в фильтре - ускорение будет путем дальнейшей оптимизации самого логического вывода фильтра - ограниченного набора только действительно нужных полей и значений

    если придумам чтото более гибкое правильное и универсальное , отпишу сюда с решением

    вообще в планах и индексы для поиска для больших БД и скрытие/неактивность характеристик неудовлетворяющих фильтрации и кол-во найденных товаров НО на ajax в отдельных потоках и тп

    • 05 марта, среда
    • Цитата
      импорте была еще тонна дублей (когда значение писалось как "220" "220в" "220вольт"/ "круг" "круглый" "окружность" и тд и тп)
      Уф... Понятно
      Цитата
      для существующих дел и в будующем для новой версии пока предлагаю внести айдишник знчения выпадающего списка и джойнить по нему

      👍 Но, опять же, проблему с кучей смысловых дублей это не решит, за исключением того, что на int можно индекс поставить. А вот если придумать инструмент, когда одному id значения характеристики можно соотносить кучу аналогичных "Круг", "Круглый", "Окружность" и при поиске они бы все выходили по одному id, это было прям хорошо. Но как это администрировать не понятно, и как изначально заносить и соотносить...
      Цитата
      ограничить для поиска выборку только характеристиками отмеченными для поиска - уже думаю пока будет достаточно
      Это да, но за исключением случаев, когда кто-то хочет у каждого значения каждой характеристики фильтра иметь циферку "Сколько будет найдено товаров по этой галке". А у нас тот же Степан эту величину клянчил долго для своего фильтра, сам её везде совал, и вот она аукивается вот так на больших разнородных таблицах. Т.к. для вывода фильтра один шиш надо перебирать всю базу предварительно
  • 06 марта, четверг
  • Цитата
    Но, опять же, проблему с кучей смысловых дублей это не решит

    ну это дело импорта я думаю - зачем в бд вообще эти дубли в принципе?
    в импорте мы сделали чтобы админ сам назначал соответствия значений в файлеимпорта/знаения характеристик сайта, не все, а так скажем список замен, что на что менять при импорте(у разных поставщиков на все и вся - свои форматы) и тогда все сведется в единые значения - те что на сайте

    Код
    но за исключением случаев, когда кто-то хочет у каждого значения каждой характеристики фильтра иметь циферку

    но все равно в филььтре должны выводиться и учавствовать в выборке в БД только характеристики отмеченные для поиска же
    а циферки, аяксом вытащим и в настройки фильтра чтобы можно отключать

    а вообще с редисом прям тема, но - она не для всех
    • 06 марта, четверг , редакция: 06 марта, четверг
    • Цитата
      а вообще с редисом прям тема, но - она не для всех

      То есть не для всех? Элементарная резидентная система управления базами данных класса NoSQL, работающая со структурами данных типа ключ - значение. Самое оно для реализации кэшей. Если весит на сокете, так ещё лучше. Но и это не предел. Переход с MySQL на Oracle также даст свои результаты. Можно и еще лучше сделать. Например, используя нейронку типа трансформер. Так что можно и дальше продолжить улучшать, главное чтоб денег хватило )
      • 08 марта, суббота
      • не для всех - в смысле не все даже и знают что это такоеи и как(и можно ли) включить на сервере, не для широких масс
        под конкретный проект - оно

Новости

  • Сегодня, 12:37
  • Мы обновили систему тарифов, учитывая опыт работы с клиентами и современные рыночные условия. Новая тарифная сетка разработана специально для того, чтобы лучше отвечать вашим потребностям. Резкого повышения цен не произошло. Более того, некоторые тарифы даже стали выгоднее и доступнее. 
  • 17 января
  • В преддверии 2025 года была выпущена сборка 7.2.5, которая не приносит радикальных изменений в функциональности, но способствует повышению стабильности работы системы и расширению возможностей облачного сервиса для создания сайтов.
  • 18 июня 2024 г.
  • В сборке большое обновление demo-шаблона, дополнительная защита от спама, улучшение YML-импорта и еще много важного и интересного.

Форум