Товары которые могут продавать вендоры - 60 шт (основные с вариациями)
Добавил вендора который взял в продажу 32 товара из 60
Зашел в БД - 93 записи в таблице products
Получается если какие-то сущности (например значения характеристик) привязаны к товару то они будут дублироваться.
Есть какие-нибудь подвижки? Карточек товаров стало на тысячу больше, около 30 тысяч. Вендоров стало побольше, но меньше 200.
Число товаров в 30к - это совсем не много. Число вендоров в пару сотен - и вовсе ерунда.
Число записей в таблице Products улетело далеко за 4 миллиона, про остальные вообще молчу.
Страница списка товаров всех вендоров открывается 70-100 секунд. Блок отображения наличия товара у продавцов генерирует тысячи запросов на странице карточки товаров, что так же занимает время и создает нагрузку(когда всё идеально - 0,3 секунды, но это только если трафика на сайте нет, а он есть всегда, как минимум от поисковых роботов).
В ядре надо исправить, как минимум, две функции. Первая - выборка товаров и подсчет пагинации.
Конкретно - вот этот запрос(кастомная его часть увеличивает время выполнения не существенно, тормозит коробочная).
SELECT
SQL_CALC_FOUND_ROWS products.product_id,
descr1.product as product,
companies.company as company_name,
products.product_type,
products.parent_product_id,
products.master_product_id,
products.company_id,
products.rf_stop_update_price,
products.rf_stop_update_amount,
products.rf_stop_update_status,
(
SELECT
SUM(amount)
FROM
cscart_products
WHERE
product_id = products.product_id
AND company_id = 1
) as geolocation_amount,
0 as geolocation_amount2
FROM
cscart_products as products
LEFT JOIN cscart_product_descriptions as descr1 ON descr1.product_id = products.product_id
AND descr1.lang_code = ‘ru’
LEFT JOIN cscart_product_prices as prices ON prices.product_id = products.product_id
AND prices.lower_limit = 1
AND prices.usergroup_id IN (0)
LEFT JOIN cscart_companies AS companies ON companies.company_id = products.company_id
INNER JOIN cscart_products_categories as products_categories ON products_categories.product_id = products.product_id
INNER JOIN cscart_categories ON cscart_categories.category_id = products_categories.category_id
LEFT JOIN cscart_product_popularity as popularity ON popularity.product_id = products.product_id
WHERE
1
AND products.company_id <> 0
AND products.product_type != ‘D’
GROUP BY
products.product_id
ORDER BY
popularity.total desc,
products.product_id ASC
LIMIT
0, 10
Вторая - выборка товаров вендоров для блока addons/master_products/blocks/products/vendor_products.tpl
4000 запросов - наверное немного перебор(увеличиваются кратно увеличению числа вендоров). А ведь товар с сотней вариаций тоже возможен и там похоже будут точно такие же проблемы(а склады не так же реализованы?).
Прошу помочь(ну или как минимум это исправить на благо своей платформы и её пользователей), у вас фактически не работает заявленный функционал. И вопрос не в железе, у меня достаточно производительный сервер - избыточная память, ядра и сверхбыстрые диски тут никак не помогают скрыть программные недоработки.
1 лайк
Выложи просто скриншот по кол-ву строк сортировку сделай, пусть народ увидит правду MVP
2 лайка
Увы… надеюсь на реакцию разработчиков. Тут ведь явно ошибка логическая, которую надо исправить.
Тут явно стоит что-то оптимизировать… 30к товаров, 8к характеристик, менее 200 вендоров. Без пары изменений в ядре сайт мгновенно ложится. С изменениями как-то работает, но есть проблемы описанные выше.
1 лайк
Как нам еще год назад пояснили: при общих товаров не надо считать головные товары а надо считать головной товар*на количество вендоров у которого он есть … т.е. по этой логике все нормально … вот только логика не очень (
Я считаю общие товары, их число на скрине видно и продавцов.
Я понимаю что вы считаете, но по логике CS общий товар это не товар, а общая карточка а товары продавцов просто не видно, но что бы купить конкретные товара он должен быть в БД и характеристики и количество и т.д. т.е. почти как вариации как один товар … вроде карточка одна а по факту в БД инфы больше чем надо
Ну логично же, если общий товар, его создает аля Модератор и там фиксировано описание, характеристики, фото, вендоры лишь кол-во и цены ставят, ну даты поступления, лейбл уценка, я бы сказал что у cs-cart нет логики вообще относительно общих товаров.
3 лайка
тут дело не в MVP и(или) общих товарах.
Столкнулся с тормозами на сервере из за этих запросов на простом cs-cart
Пробежался по форуму - а история-то древняя:
и подвижек никаких ((
Такая проблема тоже есть… особенно когда сайт начинают шерстить боты поисковиков или кто-то парсить. Парсеры практически кладут сайт, если смотреть в очереди запросов - сплошь они. Проблема настолько яркая что у меня постоянно запущен mytop чтобы отслеживать очереди и во время очередного наплыва оперативно банить.
Причем лично мне видится что проблема то на самом деле совсем не велика, действительно узких мест по пальцам пересчитать. Очень было бы хорошо исправить, сейчас это очень сильно сказывается на показателях отклика сайта учитываемых и Гуглом и Яндексом.
2 лайка
Аналогичный запрос на нормальной базе, я лечил и скорость с 5-7 секунд падала до 0.003 и он начинал даже кешироваться на захид, в случаи темы, это решение не дало вообще эффекта, там любой LEFT делает запрос не реальным, причем там проблема в том, что ответ не помещается в оперативку сервера и выполняется долгое копирование результата
1 лайк
Оперативки, кстати, не так уж и мало, на виртуалке с сайтом 49152 МБ.
Дайте какой то официальный ответ по этой теме, мы хотим понимать перспективы!
В данном измерении это не много всего 51539607552 байт это в вакууме если бы база могла забрать все, даже без джойнов это 10307 байт на строку (у тебя же 5 млн товаров) а любой джойн раздувает кол-во строк геометрически, а так как в запросе у тебя еще и название, а 1 кириллический символ 4 байта, выходит уже 2500 на строку и потом еще считаем кол-во джойнов и все. Там речь уже будет не о 5 млн
А если бы остатки по вендорам хранились в другой таблице, эта проблема бы решалась? Ведь строк в той таблице всё-равно получилось бы столько же(при наличии лишь одного склада у вендора). Таблица с полями product_id, vendor_id, warehouse_id, amount? Ну а в products - именно каталог, да и база уже была бы без всяких дублей характеристик и прочего. И добавление-убирание товара вендору бы не было тяжеленным процессом, всего-лишь добавлением строки в эту таблицу.
смотря как строить и для чего запрос, если случай с админкой, то да все было бы проще, список товаров 30к, а внутри каждого товара уже подсасывать нужную инфу по вендарам. На деле, если запрос раздробить, все будет куда быстрее работать, в твоем случае в разы быстрее. Отдельно запросить все и потом склеить.
Только это же придется переписать вообще всё что связано с MV… вот почему нельзя было сделать на базе многоскладовости этот функционал, причем тут вариации… или там так же в продуктс все остатки пихаются? Ведь это к многоскладовости намного ближе, чем к отдельным товарам…
Мышление не гибкое, все просто, так же и с вариациями можно было лучше сделать, много что можно было лучше сделать, но главное вложиться в Маркетинг, а с кодом потом лет через цать разберемся
@cs-cart_team
Можно ли что-то с этим сделать?
SELECT SQL_CALC_FOUND_ROWS products.product_id, descr1.product as product…
1 лайк