Ларчик, просто открывался!!!
Анализ БД или какие то правки в коде не помогут. С таким объемом контента необходимы правки в сервере и самой 1с. ПО другому это работать не будет.
Если новые товары выгружать покатегорийно, а цены и остатки выгружать отдельной выгрузкой - вполне может работать. При небольшой подстройке. Причем, в случае с ценами и остатками, я бы всё-таки закастомил функционал выгрузки из 1с быстрой(надо выгрузить файл и инициировать импорт обращением по ссылке), для обработки одним из существующих модулей. Быстрее было бы. Впрочем, в существующей реальности то же можно сделать и с выгрузкой новой номенклатуры - есть несколько модулей вполне работающих для загрузки товаров в CS-Cart. Нужен только модуль для выгрузки в соответствующем формате из 1с(генерация файла и экспорт фото на FTP). Наверняка есть и готовые и можно найти подходящие. Не думаю, что в данном случае в действительно нужен большой кастом на стороне карта. Импорт новых товаров из 1с реально слишком медленный, но варианты его обхода существуют.
1 лайк
Функционал работает стабильно, мы уже не одного слона скушали на импорте товаров. Даже написали специально модуль “Очередь импорта” для выгрузки от множества вендоров для исключения возможности одновременной записи в оду таблицу.
Пользователь просто не понимает, что он ограничен ресурсами своего сервера и своей 1с-ки. Для таких больших файлов необходимо донастроить сервер и саму 1с организовать и все полетит. Как вы знаете мы даем советы по организации бизнес процессов, но не не тем кто грязью поливает!
5 характеристик максимум.
Важно не число характеристик в товаре, а суммарное в магазине, совокупное число их вариантов.
А в чем важность этой информации? Мы из “ОЗОН” выгружаем всю базу, это только категорий почти 21000, характеристик более восьми тысяч, точнее 8039 и если смотреть на варианты характеристик, то только у одной характеристики “Автор” которых три в категориях с книгами насчитали более 1135000. Но и это еще не самое интересное, они хранятся не как в карте “характеристика = категория = значение = товар”, несколько посложнее “характеристика + категория = значение +категория = товар + категория”
И вто этот гиганский объем связей занимает колоссальное место в базе данных. Каталог “книги” категория + характеристика + значение = 28 гигабайт
С таким большим объемом информации сайт как летал так и летает быстро и не принужденно ))))
Да и к стати, вот модуль Add-ons :: Модуль Ozon интеграция маркетплейса для CS-Cart и Multi-Vendor на базе официального API магазина
Именно в архитектуре и проблема, серьезная проблема. Абсолютно не оптимальная. Я решил проблему, проанализировал структуру БД и написал загрузчик на Golang. То что раньше грузилось 3 минуты, сейчас загружается секунд 40.
В общем выбрали сделать костыльное решение способом который вам известен, хотя можно воспользоваться текущей архитектурой.
Оптимальным способом, уж поверьте я знаю PHP на отлично. Так как развивать данный сайт на cs-cart не имеет практического смысла. НА сайте который при открытии страницы делает 200 запросов в БД, где около 30% это повторяющиеся запросы, один только запрос на регионы РФ, делается 5 раз, разбирать и исправлять вопиющие косяки пустая трата времени, быстрее сделать сайт на адекватном движке.
Если честно я не понимаю людей, которые уперто пишут на одном языке. Язык должен подбираться под тех. задания и условия, это скорее они заперты в рамках своих компетенций вот и пишут на чем умеют.
Мне кажется, довольно очевидно что если написать что-то узкоспециализированное под задачи конкретного проекта, оно будет явно производительнее. Не нужны никакие компромиссы - всё под конкретную задачу. Минус один - кто-то должен это всё пилить и это далеко не один человек, а потом еще и поддерживать. Проще взять готовое работающее решение, быстрый сервер который кем-то преднастроен под особенности CMS и немного её доработать напильником под задачи. Быстро, дешево, можно быстро запуститься. После чего проект или со временем разовьётся и уйдет от коробки, будет переписан с нуля. Или загнется, но проблема будет уже точно не в CMS.
А оптимизировать ряд стандартных решений вот прямо вероятно надо. Есть прямо пачка стандартных блоков от коробочных блоков, которые создают чрезмерную нагрузку на ровном месте. Преимущественно в силу использования избыточных для конкретных задач стандартных функций, вызывающих другие функции и т.д… Но тогда в коробке наплодятся дополнительные минимизированные функции, которые со временем по просьбе пользователей придется расширить и они станут вновь аналогичными монстрами. Чего разработчики явно и не хотят. Так что видим неадекватно тяжелый блок - переписываем под узкую задачу и он больше мозги не парит 
Хотя, вероятно, именно блоки можно было бы и захардкодить, не используя стандартные функции, в целях оптимизации. Но противоречит идеологии. Но что-то компромиссное изобретать явно нужно. Чтобы не выходило что менюшка генерирует 1000 запросов, кеш во всём магазине скидывается при каждом обновлении остатков и т.д.
1 лайк