21.12.2017 16:57:02
Грузить свойства без нуменклатуры не выйдет. Мне даже в голову не приходило пытаться
|
|
|
|
21.12.2017 22:25:42
Вот что Битрикс ответил после недельной переписки:
- проблема не распространенная и вообще не типовой случай... "Обычно такая задача решается разделением на инфоблоки (по разделам или по типам). Каких-то штатных средств нет для ускорения продукта при таком количестве свойств." "Прочитайте статью наших специалистов по производительности: Особенное внимание уделите пункту "Неправильная структурная организация инфоблоков". Я думаю, что часть вопросов пропадёт. Если у вас есть предложения по развитию продукта, пишите на наш сайт идей: Если доработка понравится другим пользователям и разработчикам, то она будет включена в план на реализацию." В самой статье ничего нового, а по этой теме привожу отрывок - "Неправильная структурная организация инфоблоков Пожалуй, это наиболее распространенная проблема — встречается в 90% проектах (а Битрикс сказал, что не типичная проблема). Когда все товары «складывают» в один инфоблок. У такого инфоблока накапливается большое количество свойств всех товаров, это чревато большими выборками и медленным импортом. Рассмотрим на примере абстрактного спортивного магазина, у которого в ассортименте одежда, лыжи, велосипеды (и у каждого вида товаров свои свойства). Свойства товаров попадают в один инфоблок, велосипеды получают свойства лыж и одежды (и, соответственно, наоборот — данные виды товаров получают свойства велосипедов). Представьте, сколько «избыточных» свойств накапливается, если категорий товаров у магазина много. При этом однажды мы столкнулись с противоположной проблемой: у проекта была правильная структура инфоблоков, но также было много агрегирующих выборок (новинки, акции, хиты). Получилось, что вместо одного запроса в «долгий» инфоблок для генерации выборки отправлялось по запросу в 50+ быстрых инфоблоков и затем ещё происходило их совмещение в коде. Из-за этого компонент в целом стал работать медленнее. Так что если проекту необходима такая функциональность, то надо разрабатывать запасной план — создавать отдельную таблицу в базе данных (делать «денормализацию» структуры инфоблоков), либо через внешнюю агрегацию, либо что-то ещё." |
|
|
|
22.12.2017 10:38:52
|
|||
|
|
22.12.2017 11:11:00
Подготовил ссылки на темы по данной проблеме, может кому то полезно будет:
1. Как хранить большое количество характеристики товара? - 2. Каталог тормозит от большого количества свойств - 3. Организация инфоблока с большим количеством элементов - 4. Значения свойств элементов инфоблоков - какой вариант самый оптимальный? - 5. Максимальное количество свойств инфоблоков ограничено? Не сохраняются настройки инфоблока. - 6. При создании свойства выдается ошибка - 7. Битрикс тормозит при большом количестве свойств - 8. Битроник: 2-е архитектуры торгового каталога на выбор! - |
|
|
|
27.12.2017 11:40:02
Вы пробывали хранить часть свойств(не фильтруемых) одной строкой как текстовое описание ? У меня экономия на этом до 10к(95%) свойств.
|
|
|
|
27.12.2017 16:13:56
|
|||
|
|
09.01.2018 12:19:34
Тут, я думаю, просто нужно разбить справочник на несколько других справочников, ведь несколько тысяч элементов - это очень много для хайлоад блока. Нужно разбить их по нескольким таблицам, сделать еще одну таблицу, в которой были будут прописаны связи между этими таблицами и немного переделать АПИ. Не понимаю, чего не хватает этим разработчикам - тут работы минут на 20. И вообще, во всех нормальных проектах в справочниках не более 10 элементов, а, если больше, то это уже отдельный нестандартный проект уровня Эльдорадо.
|
|||||||||||||
|
|
09.01.2018 15:26:53
|
|||
|
|
09.01.2018 15:39:53
Оставил всего одно основное свойство для всего каталога здесь:/bitrix/admin/cat_catalog_edit.php?lang=ru&IBLOCK_ID=#IBLOCK_ID# Для раздела добавил одно дополнительное свойство для отображения по адресу: /bitrix/admin/cat_section_edit.php?IBLOCK_ID=#IBLOCK_ID#&type=#IBLOCK_TYPE#&ID=#SECTION_ID#&lang=ru&from=iblock_section_admin&find_section_section=0 В итоге на странице редактирования элемента все равно вываливаются абсолютно все свойства инфоблока. (элемент привязан к единственной отредактированной секции). Ок, удалил почти все свойства из настроек формы редактирования элемента - да, они не показываются, но они все равно подгружаются, если посмотреть исходные код, в итоге страница редактирования элемента занимает около 5 мегабайт с отключенным отображением ненужных свойств как в настройках формы редактирования, так и в настройках раздела, к которому привязан товар. Что я делаю не так? |
|||
|
|
09.01.2018 15:50:20
забавно что до сих пор не решена проблема с большим кол-вом свойств. накой черт тогда эт инфоблоки нужны?
храни в json поле - там и фильтровать можно и индексирование есть и гемора нет с распределением и поддержкой наборов свойств - можно хранить какие угодно наборы. голосуйте за идею или реализуйте совместимый api и продавайте в своем решении ecommerce - идея для стартапа. которая в теории должна принести кучу денег ее разработчикам. |
|
|
|
09.01.2018 16:12:16
|
|||
|
|
10.01.2018 17:34:38
ну это и будет по сути таблица как вы это называете "чистый мускуль"
просто завернутая в совместимый api |
|
|
|
11.01.2018 10:40:33
Но для торговых предложений оно так не работает. |
|||
|
|
06.06.2018 15:11:22
Из коробки Битрикс с большим количеством свойств к сожалению работать пока не может! В результате - глубоко переделали компоненты смарт.фильтров, сделали много мелких доработок в компонентах торгового каталога, тонко донастроили кеширование а также полностью перенастроили WEB-окружение битрикса в CentOS и подтюнили саму OS (файловые и системные лимиты, работу с сетевым стеком и т.д.). Но самое главное - перешли полностью на простые строковые свойства глобально для всего каталога!
В результате - потеряли возможность контролировать сортировку в выводе значений свойств в фильтрах, но получили вполне рабочий магазин на 50-60k+ товарах с 8k+ свойств... может кому интересно как это сейчас выглядит (не рекламы ради) - kpi-market . com - работает в виртуальной машине с 4 ядрами от Xeon 1240v6 ( Ну и продолжаем активные доработки, планируем вернуться к свойствам с различными типами (не только строка) и т.д... |
|
|
|
28.05.2019 13:13:55
платформа supermicro непомню точную модель - проц e2146g - память ddr4 64гб - ssd 0+N - esxi там уже пара идентичных машин продакшн и тест ресурсы между ними поделены так: -на боевой 40гб памяти -на тест 10гб -проц весь на боевой на тест ограничено до 4 потоков. на тесте битиркс дает такую картину НО каталог из админки всяко тормозит ! а как из опыта всенародного видно тормозит из за дикого количества свойств пример |
||||
|
|
|||