Тут явно стоит что-то оптимизировать… 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 лайк