Есть проблема с каталогом - начали сильно тормозить модули фильтров, SEO-фильтров от AB.
Характеристики для всех товаров вендоров дублируются?
Общие товары продавцов, всего несколько десятков вендоров, всего 28к товаров. Проблема с сильными тормозами каталога товаров и блокировки БД в целом.
Что-то прямо беда.
Кто там говорил про маркетплейсы, про общие товары продавцов? Вопрос - а как оно вообще предполагалось что должно было работать? Мало того что в таблице Products решение странное. Но ладно - пусть будет, наверное имеет право на жизнь такое решение. А тут - это БАЖИЩЕ. Всего меньше 30к товаров. Меньше 60 вендоров. Всё, страницы каталога умирают т.к. допущены грубые архитектурные ошибки.
Что мне с этим делать, прошу подсказать. У меня вендоров должно быть сильно больше. А уже сейчас проблема с фильтрами.
@cs-cart_team Вероятно, тему стоит перенести в баг-трекер.
Это удивительно… и неправильно 
Не может это работать шустро. Уже сейчас 20 миллионов строк. А это 5% от запланированного числа вендоров. Что с этим делать - вообще не понятно.
Кстати, количество записей, меньше месяца назад… Товаров примерно столько же. Ну, плюс-минус несколько сотен товаров. Категорий столько же. Записей в таблицах БД… на скринах. Увеличилось только количество вендоров, причем всего в пару раз. Было где-то коло 20-25, стало около 60. Это единственное что изменилось за это время.
Вопросы: почему так растут таблицы с ссылками на фотографии и значения характеристик товаров, другие? Тут что-то прямо совсем не так. А что будет когда вендоров станет 500? А 5000? Хотя бы теоретически то возможно с таким количеством работать, или архитектурно это невозможно? У меня складывается впечатление что я вляпался.
Что я делаю не так? Вот карточки товаров, не миллион, их всего 28к. У меня в личном мелком интернет-магазине товаров существенно больше, чем в этом маркетплейсе. Есть вендоры, планируется несколько тысяч. Не WB, не OZON, масштаб не великий, всего несколько тысяч. Это невозможно, выходит, работать не может?
Мне бы понять что с этим делать сейчас…
Опишите, пожалуйста, проблему подробнее. Сейчас в топике много эмоций и почти никакой конкретики, поэтому он никак не тянет на багрепорт.
Сколько в магазине товаров и характеристик? На одном скрине я вижу 1.5 миллиона строк в таблице с товарами, а не 28к. На последнем скрине их 800к. В таблице product_feature_values хранятся значения характеристик выбранные для товаров, т.е. ее размер зависит от числа товаров и характеристик.
Если вы напишете в Help desk, то мы сможем изучить конкретную установку клиента
Да, эмоций много… Потому что товаров 29к(чуть добавилось), а число строк в таблице cscart_product_features_values имеет прямую корреляцию с числом вендоров, а не числом товаров. Записей в этой таблице уже 20 миллионов. А к этой странице идет обращение на страницах каталога, к ней естественно обращается модуль СЕО-страниц для фильтров. Это создает большую нагрузку на БД и сайт периодически просто падает. Это не единственная проблема, но в данный момент главная. А ведь число вендоров только-только начало расти.
Разница между скринами в 800к и полтора миллиона строк - всего несколько недель и примерно в два раза увеличившееся число вендоров. Число характеристик и товаров практически не изменилось за это время.
Число характеристик на сайте 7811, категорий 1115, товаров в каталоге карточек товаров 29092, продается вендорами 24226(остальные карточки товаров или не включены ни у одного из вендоров, или включены у одного). Вендоров включено всего 50, еще 9 имеют статус Неподтвержденный(но товары уже добавлены). Фильтров настроено 4158 штук(все фильтры только на категории последнего уровня, кроме брендов).
Ничего экстраординарного в целом, сайт среднего уровня проработки, нет огромных объемов чего бы то ни было. А проблемы уже большие. И я вижу ОЧЕНЬ сильно смущающие меня логические моменты. Я не хотел плодить миллионы карточек товаров, объединяя их между собой, потому я искал решение с общим каталогом карточек товаров. И был рад что нашел это решение в CS-Cart, на которую с CS-Cart же было просто перейти. А сейчас я смотрю в таблицы БД и у меня какие-то нехорошие чувства.
Скажите, что мне сделать чтобы я смог добавить на сайт 6000 вендоров? Вопрос, между прочим, совсем не праздный. Я хочу это сделать до конца 2020 года.
Пожалуйста, создайте обращение в Help desk. Мы изучим магазин и постараемся предложить решение. Без изучения в установке сложно найти какое-то конкретное решение.
Продублировал
О результатах расскажите
Те же проблемы, никак не могу расшириться не по количеству вендоров, характеристик и т.д., по началу все работает шустро, пока не дойдет до определенного количества характеристик, (это по моему мнению, может проблема в другом), суть в том что и в один момент, как будто в базе данных что-то происходит и она умирает, после чего с фильтрами вообще не возможно работать, все насколько долго отвечает, та и с товарами таже история, чем больше характеристик сохраняешь в карточке, тем дольше не отвечает база данных, пока она перегрузится, вследствие чего загрузка процесора, сайт не отвечает, и негатив для поисковых машин, и как можно составить конкуренцию другим сервисам, если на них несколько миллионов товаров
Я надеюсь @redrikshukhart не будет против, если я кратко расскажу что выяснил мой коллега изучив установку.
Сейчас в магазине 1,45 миллиона товаров и 7812 характеристик. Т.е. максимальное число записей в таблице product_feature_values может составить 11 327 400 000, если для каждого товара доступны все характеристики.
В данном случае в среднем на каждый товар приходится по 13,7 характеристик. Таким образом в таблице product_feature_values около 20 миллионов записей.
Мы не нашли необъяснимо большого числа записей в таблице с характеристиками. Ее размер соответствует числу товаров и характеристик.
В релиз 4.12.1 войдут изменения, которые должны ускорить работу фильтров в магазинах с большим числом товаров. Этот релиз выйдет после 4.11.5. Ориентировочно во второй половине осени, но точной даты пока нет.
Я немного не понял. Так полтора миллиона товаров, или 29 тысяч?
Получается, 50 вендоров, и каждый товар уже существует в пятидесяти копиях. Если у товара 20 характеристик - то в итоге имеем для ОДНОГО товара 1000 записей значений характеристик. Верно я понимаю?
Вы опять ничего не изучили. Ну как можно вот так смотреть в экран и ничего не видеть? Это же ваш продукт, ваш заявленный функционал, на который я специально обратил внимание и в заголовке темы и в тексте и отдельно скриншоты маркетинговых страниц привел. Еще раз, режим Общие товары продавцов! Товаров всего 29к. Нет больше. У вендоров вообще прав на создание товаров нет, все товары которые могут продавать вендоры - вот этот список заранее подготовленных. А то что полтора миллиона записей в таблице products - ну так это не более чем особенность вашей же реализации данного режима работы. Количество товаров от того не увеличивается. Проблема в том что эта таблица, а вместе с ней и таблица характеристик плодится не от увеличения числа товаров, а от увеличения числа вендоров.
Это же и без изучения моей установки очевидно. Я тут описал, можете сами попробовать у себя…
Еще раз. Если на сайте будет всего 1 карточка товаров, 10 характеристик у этого товара. И 1000 вендоров, то в таблице products будет 1001 запись, а в таблице cscart_product_features_values будет… 10000 записей? Вам не кажется тут ничего странного? Откуда у одного товара такое количество характеристик уродилось?
Я про то что у меня проблема. Тут очевидный косяк, который мне надо как-то решить. И я прошу помощи. У меня уже тяжко страницам каталогов т.к. тяжеленные запросы фильтров с участием этой таблицы подвешивают сайт. Фильтры не отключить т.к. товары иначе практически не найти. А вендоров должно скоро стать не 50, а 6000. И очевидно что если ничего не делать, то это невозможно. А делать то надо не только мне - тут косяк то в ядре. Я с одной стороны хочу указать на ошибку, а с другой - прошу помощи…
Ух ты темища! 
Пожалуй я подсуечусь!
@cs-cart_team По ощущениям на моем сайте что-то похожее. Еще год назад писал на форуме и обращался в техподдержку о том, что моя cms-ка выкидывает номера, то виснет, то запросы к БД зашкаливают. Хорошо, что нынче хостинг у меня гибкий, позволительно большое превышение пиков за счет соседей, а если бы не так, то сайт бы постоянно падал, собственно так и было на предыдущем хосте. Так вот похоже нашелся ключик, по всей видимости в моей БД аналогичная проблема. Только вот я самостоятельно проверить и оценить, действительно то же самое или нет не могу, пардон, не специалист в этой области. 
Товары которые могут продавать вендоры - 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 запросов - наверное немного перебор(увеличиваются кратно увеличению числа вендоров). А ведь товар с сотней вариаций тоже возможен и там похоже будут точно такие же проблемы(а склады не так же реализованы?).
Прошу помочь(ну или как минимум это исправить на благо своей платформы и её пользователей), у вас фактически не работает заявленный функционал. И вопрос не в железе, у меня достаточно производительный сервер - избыточная память, ядра и сверхбыстрые диски тут никак не помогают скрыть программные недоработки.
Выложи просто скриншот по кол-ву строк сортировку сделай, пусть народ увидит правду MVP
Увы… надеюсь на реакцию разработчиков. Тут ведь явно ошибка логическая, которую надо исправить.
