Уменьшение запросов к базе данных Opencart v3

[susl16c]

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

Хотелось бы в идеале чтобы было 20-30 запросов, даже если для решения этого требуется установить доп ПО.

[OtezVikentiy]

2 часа назад, susl16c сказал:

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

А откуда у вас вообще ТАКОЕ количество запросов с 1 страницы то? Это прям ад какой-то... о_О Что там столько запрашивается?
 

2 часа назад, susl16c сказал:

Хотелось бы в идеале чтобы было 20-30 запросов, даже если для решения этого требуется установить доп ПО.

Вот как раз из-за доп ПО у вас и есть 310 запросов...

Вам как раз нужна ручная оптимизация, а не доп ПО. 310 запросов с 1 страницы - это прям овермного. Даже 20-30 это многовато... Что там за страница то такая?

[susl16c]

Да просто товар выложен и все, такое ощущение, что каждая единица делает запрос на получение данных.

Все блоки выводятся средствами темы и чем их больше тем больше запросов.

Змінено 16 лютого 2021 користувачем susl16c

[OtezVikentiy]

20 минут назад, susl16c сказал:

Да просто товар выложен и все, такое ощущение, что каждая единица делает запрос на получение данных.

Ну собственно надо код профилировать сидеть. Либо объединять запросы либо как-то группировать, но это все вручную и сильно трудозатратно. Скорее всего там просто установлено модулей 100500 штук, которые каждый делает свой запрос на выгрузку плюс-минус одних и тех же данных. Потому что в движке из коробки нет даже 20 запросов к БД... Про 310 я уже вообще молчу...

Кстати, а как вы поняли что там 310 запросов в БД? Может там 310 запросов к бэкэнду на выполнение каких-то скриптов? Или прям реально 310 запросов именно в БД происходит с 1 страницы?

[rb2]

1 hour ago, OtezVikentiy said:

А откуда у вас вообще ТАКОЕ количество запросов с 1 страницы то? Это прям ад какой-то... о_О Что там столько запрашивается?

Что вас так удивляет? Я не помню реальных цифр, но вроде для опенкарта это вполне норма.
Одно меню построить - там кучу запросов опенкарт делает.

 

[susl16c]

Ну может я не верно их замеряю сюда https://tools.pingdom.com/ кидал сайт и он показывает количество запросов, при открытии страницы к базе один запрос sleep но много кешей работают и еще несколько индексов в базе чтобы быстрее выборки шли. А раньше с 5к товара и админка туупила сейчас пока норм работает. Да оптимизация у опена задница по сравнению например с XenForo у которого 18 запросов всего.

Змінено 16 лютого 2021 користувачем susl16c

[Yoda]

3 часа назад, susl16c сказал:

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

Хотелось бы в идеале чтобы было 20-30 запросов, даже если для решения этого требуется установить доп ПО.

 

У вас неправильная формулировка вопроса.
Необходимо не сокращать запросы.

А делать их быстрыми и сокращать. Так как может быть один запрос на 1секунду и 200 по 0.0001.

 

 Кроме того существуют иные узкие места, как то излишние количество файлов в папках, некорректная логика работы скриптов и так далее!

 

Ну и в целом ваш вопрос звучит так, есть красивая женщина, но стервозная и тупая и дерется.
Давайте ей отрежем руки и ноги. Оставим только то что нам приятно.

[Yoda]

3 минуты назад, susl16c сказал:

Ну может я не верно их замеряю сюда https://tools.pingdom.com/ кидал сайт и он показывает количество запросов, при открытии страницы к базе один запрос sleep но много кешей работают и еще несколько индексов в базе чтобы быстрее выборки шли. А раньше с 5к товара и админка туупила сейчас пока норм работает. Да оптимизация у опена задница по сравнению например с XenForo у которого 18 запросов всего.

Это анекдот!
pingdom показывает количество коннектов к серверу.

Вы сейчас спутали хрен с  редькой!

[susl16c]

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

[rb2]

LOL

+1 про оптимизацию запросов.
Это комплексная задача.

[OtezVikentiy]

Только что, rb2 сказал:

Что вас так удивляет? Я не помню реальных цифр, но вроде для опенкарта это вполне норма.
Одно меню построить - там кучу запросов опенкарт делает.

 

Ну вообще 310 отдельных запросов в БД для одной страницы даже с учетом меню - это очень много. Отсюда и удивление такое.
Потому что ну выгрузить товары например для 10 блоков... ну это 10 запросов...
Собрать меню например ну еще 5 запросов...
Ну допустим еще 5-7 запросов набросим... Итого 22 запроса в БД отдельных - и то это многовато и можно оптимизировать в несколько раз в идеальных условиях.
Но как бы... еще 280 запросов - это вообще куда? Вот отсюда и удивление, потому что это реально слишком много и абсолютно точно это не нормально.

Да, в опенкарте не идеальная архитектура БД, но не настолько, что 300+ запросов с 1 страницы в БД.

[OtezVikentiy]

4 минуты назад, susl16c сказал:

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

Это не запросы к базе данных - это запросы к серверу. Это вообще не одно и то же 

[susl16c]

ДА вы правы я спутал, это количество запросов к вебсерверу для визуализации страницы и причем на вебе pagespeed mod стоит он собирает css и js и все равно это дохрена конечно.

С базой жопа когда грузится товара и без индекс она почти раком проц ставит хотя запросов не много.

Змінено 16 лютого 2021 користувачем susl16c

[OtezVikentiy]

7 минут назад, susl16c сказал:

ДА вы правы я спутал, это количество запросов к вебсерверу для визуализации страницы и причем на вебе pagespeed mod стоит он собирает css и js и все равно это дохрена конечно.

С базой жопа когда грузится товара и без индекс она почти раком проц ставит хотя запросов не много.

Ну вот собственно Yoda уже ответил. Оптимизация - это комплексный подход и довольно не быстрый процесс. Собственно ищите опытного разработчика, который готов будет этим заняться. )))

Сказать что вот поставь модуль такой-то или удали кусочек там-то - тут так не получится. Это сидеть, смотреть, разбирать, профилировать код, оптимизировать запросы к БД, смотреть на обращения к серверу, всю цепочку от начала и до конца. Кропотливый процесс.

[Bn174uk]

Так может ТС хотя бы ссылку дал на сайт. Может быть у него на странице по 50+ товаров + к каждому товары выводятся атрибуты + опции + дисконт + еще и фотогаллерея.

А так получается, говорил про 300+ запросов к базе, а оказалось дело не в базе, а сервере.

 

Ну а дальше поставить обычный sql profiler и посмотреть, что за запросы.

Недавно у клиента были траблы со скоростью.

Начал смотреть и оказалось дело было просто в одном запросе который грузил базу на 1-1.5 сек и так на каждой странице.

После лечения сайт стал летать. 

 

[Yoda]

9 минут назад, Bn174uk сказал:

Так может ТС хотя бы ссылку дал на сайт. Может быть у него на странице по 50+ товаров + к каждому товары выводятся атрибуты + опции + дисконт + еще и фотогаллерея.

А так получается, говорил про 300+ запросов к базе, а оказалось дело не в базе, а сервере.

 

Ну а дальше поставить обычный sql profiler и посмотреть, что за запросы.

Недавно у клиента были траблы со скоростью.

Начал смотреть и оказалось дело было просто в одном запросе который грузил базу на 1-1.5 сек и так на каждой странице.

После лечения сайт стал летать. 

 

А что такое летать ?
В моем понимании - это магазин на 100 000 товаров  с фильтром без джек плеши ttfb 150-500 мс в категории под нагрузкой от реальных посетителей в 50-100 одновременных подключений.
Это летать.

[Bn174uk]

4 минуты назад, Yoda сказал:

А что такое летать ?

Давайте только без этих всех пантов и придирок к словам.

Я не рвусь отбирать Ваш хлеб и тем более получить звания профи в оптимизации серваков/запросов к бд и т.д.

 

Мои слова относились к проблеме моего клиента в целом, то что было до и то что стало после решения проблемы.

Дальнейшею дискуссия по этому вопросы продолжать не стану, зашел лишь просто дать совет ТС.

Себя(как исполнителя) не предлагаю в решения проблемы ТС.

[Yoda]

1 час назад, Bn174uk сказал:

Давайте только без этих всех пантов и придирок к словам.

Я не рвусь отбирать Ваш хлеб и тем более получить звания профи в оптимизации серваков/запросов к бд и т.д.

 

Мои слова относились к проблеме моего клиента в целом, то что было до и то что стало после решения проблемы.

Дальнейшею дискуссия по этому вопросы продолжать не стану, зашел лишь просто дать совет ТС.

Себя(как исполнителя) не предлагаю в решения проблемы ТС.

Да где понты. Бросьте эти закидоны в стиле анюкчи.

Мне реально интересно что в понимании людей быстрый магазин!
 

[Prooksius]

4 часа назад, OtezVikentiy сказал:

Собрать меню например ну еще 5 запросов...

Не знаю, о каком вы меню, но если структура категорий разветвленная - запросов будет много, никак не 5.
К тому же еще для каждой категории идет подсчет количества товаров (если, правда, не отключено в админке)

Да что уж говорить, если даже в категории получаем список товаров одним запросом, а потом по каждому товару еще отдельно запрос, а в нем повторно запрашивается кое-что, что запрашивалось в первом..

Еще, если включен подсчет количества товаров в категориях, и очень много мелких категорий, надо обязательно делать один индекс в таблице oc_category_path
Пришлось долго анализировать (через EXPLAIN) запрос этого подсчета количества в категориях и отловил, что он нерационально соединяет таблицы в некоторых случаях. 
Индекс нужен по полю path_id, именно отдельно по нему
У меня был магазин с 30к товаров и вот этот индекс очень сильно ускорил работу сайта.

Змінено 16 лютого 2021 користувачем Prooksius

[Yoda]

1 час назад, Prooksius сказал:

Не знаю, о каком вы меню, но если структура категорий разветвленная - запросов будет много, никак не 5.
К тому же еще для каждой категории идет подсчет количества товаров (если, правда, не отключено в админке)

Да что уж говорить, если даже в категории получаем список товаров одним запросом, а потом по каждому товару еще отдельно запрос, а в нем повторно запрашивается кое-что, что запрашивалось в первом..

Еще, если включен подсчет количества товаров в категориях, и очень много мелких категорий, надо обязательно делать один индекс в таблице oc_category_path
Пришлось долго анализировать (через EXPLAIN) запрос этого подсчета количества в категориях и отловил, что он нерационально соединяет таблицы в некоторых случаях. 
Индекс нужен по полю path_id, именно отдельно по нему
У меня был магазин с 30к товаров и вот этот индекс очень сильно ускорил работу сайта.

Серьезно?
У меня есть магазин на 3м товаров. 

Поможет ?

[Prooksius]

9 часов назад, Yoda сказал:

Серьезно?
У меня есть магазин на 3м товаров. 

Поможет ?

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

[susl16c]

Скажите а такое возможно domain sharding на Opencart реализовать чтобы параллейно закачивались картинки и за счет этого увеличилась скорость загрузки контента ? Возможно кто то делал что то подобное ?

[OtezVikentiy]

11 часов назад, Prooksius сказал:

Не знаю, о каком вы меню, но если структура категорий разветвленная - запросов будет много, никак не 5.
К тому же еще для каждой категории идет подсчет количества товаров (если, правда, не отключено в админке)

Да что уж говорить, если даже в категории получаем список товаров одним запросом, а потом по каждому товару еще отдельно запрос, а в нем повторно запрашивается кое-что, что запрашивалось в первом..

Еще, если включен подсчет количества товаров в категориях, и очень много мелких категорий, надо обязательно делать один индекс в таблице oc_category_path
Пришлось долго анализировать (через EXPLAIN) запрос этого подсчета количества в категориях и отловил, что он нерационально соединяет таблицы в некоторых случаях. 
Индекс нужен по полю path_id, именно отдельно по нему
У меня был магазин с 30к товаров и вот этот индекс очень сильно ускорил работу сайта.

Если у вас древовидное тяжелое меню и по товарам надо делать дополнительные выгрузки - есть вариант сделать рефакторинг архитектуры БД например и не страдать 20+ запросами в БД. ))) Меню и товары - в 99% случаев это по большей степени статика, которая меняется, ну окей... пусть будет даже если 2-3 раза в день, но никак не 100 раз в минуту например. Соответственно в случае, если у вас действительно все прям настолько сложно, что нужно делать овермного запросов на стоковой БД и все это большое и тяжелое - сделайте 2 отдельные таблицы где будете хранить нужные данные в нужном виде и делайте вместо 20-30 запросов - 2 запроса... ))) И обновляйте эти таблицы по триггеру. Да, у нас получается оверхэд по хранению данных и получается, что надо следить за консистентностью, но за то у нас вместо 30 запросов - 2.

Это конечно возможно не идеальное решение, но проблему точно решает.

[susl16c]

Подскажите как настроить хранение картинок на поддомене ? чтобы параллейно раздавать контент. Да нужно заморочится конкретно чтобы сайт был пуля )))

Змінено 17 лютого 2021 користувачем susl16c

[OtezVikentiy]

Только что, nikifalex сказал:

а что за триггер такой?

Событие. Можно сделать на уровне БД, а можно сделать на уровне того же опенкарта, если событийная модель не сломана.

При обновлении данных по товару через админку - обновляем соответствующие данные в новых таблицах плоских, которые для быстрой выдачи сделаны.