Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

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


Recommended Posts

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

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

Надіслати
Поділитися на інших сайтах


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

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

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

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

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

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

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

Надіслати
Поділитися на інших сайтах

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

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

Змінено користувачем susl16c
Надіслати
Поділитися на інших сайтах


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

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

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

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

Надіслати
Поділитися на інших сайтах

1 hour ago, OtezVikentiy said:

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

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

 

Надіслати
Поділитися на інших сайтах


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

Змінено користувачем susl16c
Надіслати
Поділитися на інших сайтах


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

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

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

 

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

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

 

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

 

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

Надіслати
Поділитися на інших сайтах


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

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

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

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

  • +1 1
Надіслати
Поділитися на інших сайтах


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

Надіслати
Поділитися на інших сайтах


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

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

 

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

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

Надіслати
Поділитися на інших сайтах

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

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

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

Надіслати
Поділитися на інших сайтах

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

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

Змінено користувачем susl16c
Надіслати
Поділитися на інших сайтах


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

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

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

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

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

Надіслати
Поділитися на інших сайтах

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

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

 

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

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

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

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

 

Надіслати
Поділитися на інших сайтах

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

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

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

 

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

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

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

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

 

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

Надіслати
Поділитися на інших сайтах


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

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

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

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

 

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

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

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

  • +1 1
Надіслати
Поділитися на інших сайтах

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

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

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

 

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

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

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

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

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

Надіслати
Поділитися на інших сайтах


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

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

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

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

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

Змінено користувачем Prooksius
Надіслати
Поділитися на інших сайтах

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

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

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

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

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

Поможет ?

Надіслати
Поділитися на інших сайтах


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

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

Поможет ?

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

Надіслати
Поділитися на інших сайтах

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

Надіслати
Поділитися на інших сайтах


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

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

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

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

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

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

  • +1 1
Надіслати
Поділитися на інших сайтах

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

Змінено користувачем susl16c
Надіслати
Поділитися на інших сайтах


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

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

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

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

  • +1 1
Надіслати
Поділитися на інших сайтах

Створіть аккаунт або увійдіть для коментування

Ви повинні бути користувачем, щоб залишити коментар

Створити обліковий запис

Зареєструйтеся для отримання облікового запису. Це просто!

Зареєструвати аккаунт

Вхід

Уже зареєстровані? Увійдіть тут.

Вхід зараз
  • Зараз на сторінці   0 користувачів

    • Ні користувачів, які переглядиють цю сторінку

×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.