Перейти к публикации
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...

PaulMoriarty

Новичок
  
  • Публикаций

    2
  • Зарегистрирован

  • Посещение

Достижения PaulMoriarty

Newbie

Newbie (1/14)

  • First Post
  • Week One Done
  • One Month Later
  • One Year In
  • Conversation Starter

Последние медали

0

Репутация

  1. Сразу хочу оговориться, с php и MySql я знаком очень-очень шапочно. Попросили посмотреть, что тормозит. Что-то переписывать и переделывать под себя я категорически не желаю. Недоумение вызвал тот факт, что достаточно простенькая страница может грузиться так долго. Еще больше недоумения, когда выяснилось, что эта страничка делает несколько сотен запросов в БД. И окончательно добил факт, что тормозят эти счетчики еще с 1-ой версии OpenCart. Сейчас уже третья, а воз и ныне там. Я может чего не понимаю, но такие вещи должны работать "из коробки", безо всяких настроек, допиливаний и кэширований, тем более проблеме уже несколько лет и много версий. Сервер свой, не хостинг. Конфиг: 2-ядерный Xeon 5160 @ 3 ГГц; RAM - 4 Гб; Windows Server 2008 R2, IIS 7.5; PHP 7.3.2; MySql 5.5. Количество товаров, что-то около 67-68 тыс. Но это все мелочи. Одна относительно средняя таблица соединяется с парой-тройкой мелких. Должно работать мгновенно. На SqlServer я просто не задумываюсь о настройке подобных запросов. Написал похожий на мой, то что с группировкой, ради интереса. Таблица товаров далеко за 100.000 записей, категорий около 1000. Запрос выполнился за 20 мсек. Какие там могут быть долгие блокировки?
  2. Добрый день. Столкнулся с долгой загрузкой страницы. Более минуты. Вывел лог запросов с MySql и увидел следующую картину - множество запросов вида: SELECT count(DISTINCT p.product_id) AS total FROM oc_product_to_category p2c LEFT JOIN oc_product_filter pf ON (p2c.product_id = pf.product_id) LEFT JOIN oc_product p ON (pf.product_id = p.product_id) LEFT JOIN oc_product_description pd ON (p.product_id = pd.product_id) LEFT JOIN oc_product_to_store p2s ON (p.product_id = p2s.product_id) WHERE pd.language_id = '1' AND p.status = '1' AND p.date_available <= now() AND p2s.store_id = '0' AND p2c.category_id = '59' AND pf.filter_id IN (272) Такой запрос выводит количество товаров в скобках по каждому фильтру. Один такой запрос выполняется на моем сервере около 0,6 сек. Вроде немного. Но! Фильтров на странице 106 штук. Почему нельзя было сделать все одним запросом? SELECT pf.filter_id , count(DISTINCT p.product_id) AS total FROM oc_product_to_category p2c LEFT JOIN oc_product_filter pf ON (p2c.product_id = pf.product_id) LEFT JOIN oc_product p ON (pf.product_id = p.product_id) LEFT JOIN oc_product_description pd ON (p.product_id = pd.product_id) LEFT JOIN oc_product_to_store p2s ON (p.product_id = p2s.product_id) WHERE pd.language_id = '1' AND p.status = '1' AND p.date_available <= now() AND p2s.store_id = '0' AND p2c.category_id = '59' AND pf.filter_id IN (272,...много чисел..., 284) GROUP BY pf.filter_id А потом результирующую таблицу распарсить, десериализовать и т.д. до отдельного фильтра? В итоге исходный вариант работает больше минуты. Мой вариант - 3.5 секунды. И те же вопросы по остальным запросам. Все товары грузятся однотипными запросами. На странице 20 товаров - будет 20 запросов; 100 товаров - 100 запросов. Там меняется только id. Неужели за раз нельзя все выгребать? P.S. В интернете нашел рекомендации по ускорению сайтов OpenCart. Там народ просто отключает в коде вычисление и отображение этих счетчиков на странице (количество товаров, количество категорий и т.д.). Вот это вообще как?
×
×
  • Создать...

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.