После произведенного импорта элементов, для примера элементов - товаров на сайт возникает проблема с выводом списка элементов в административном разделе системы.
[spoiler]
В первом случай это ошибка "Fatal error: Allowed memory size ..." при выводе списка элементов в административном разделе системы.
Проблему можно устранить отключив режим "Совместный просмотр разделов и элементов:" в настройках модуля информационных блоков.
решение описано
Во втором низкая скорость генерации станицы списка элементов в административном разделе системы.
При включении отладки видим, что основное время генерации страницы составляет выполнение запросов а) пересчета элементов в ИБ
б) и выборка определенного числа элементов с сортировкой
Проблема связан в первую очередь с особенностями работы самой БД, а низкая скорость генерации в административной части это уже следствие.
На примере показан один из таких каталогов который получен генератором элементов о котором я напишу ниже.
Он содержит порядка 400 000 элементов
Время генерации страницы административного раздела 7.5452 секунды из которых на работу БД отведено 6.7765.
Для достижения приемлемой работы в административном разделе необходимо
1 использовать фильтр по полям или свойствам, что не всегда удобно
На примере мы выбираем определенный диапазон элементов по их id
Время генерации странице 0.5656 секунд из которых на работу БД отведено 0.2241.
2 Либо распределение элементов по секция - тем самых классифицируя их только в административной части, при этом совсем необязательно производить деление элементов при выводе в публичной части на секции.
Создаем секции в ИБ и размещаем элементы в секциях
Полученное время генерации при первом обращении к содержимому ИБ 0.0279 секунд
При этом необходимо убедиться, что в списке секций не выводится количество элементов в секциях
Далее при просмотре элементов в каталоге в определенной подсекции время генерации составляет 0.7208 секунд, что является уже приемлемым временем генерации страницы
списка элементов
В данной ситуации работу с каталогом уже можно считать приемлемой.
Безусловно, что при этом производительность сервера БД должна является достаточной
Для контроля просматриваем отчет монитора производительности и страницу настроек сервера БД уделяя особое внимание параметру query_cache_size
Необходимо так же помнить о регулярной оптимизации таблиц БД
Проблема с генерацией списка элементов наиболее актуальна на серверах с невысокой производительностью сервера БД и большими каталогами (например каталог авто запчастей)
число элементов в которых может достигать 2 и более млн элементов в корне информационного блока, при том, что данные элементы могут быть достаточно просто классифицированы по секциям.
Таким образам для избежания возможных неудобств в работе в административном разделе в случае большого числа элементов, рекомендацией может стать использование секций если данные могут быть классифицированы и распределены
Теперь коротко о генераторе элементов.
Данный скрипт является демонстрационным и для использования необходимо производить отдельное тестирование с возможной доработкой под свои задачи.
По этой причине я подробно не останавливаюсь на данном скрипте.
Скрипту для генерации элементов и структуры данный необходим только созданный тип ИБ bx
В процессе работы работы срипт сам создаст ИБ и всю необходимую структуру данных.
В секции элементов и секций указывается количество элементов и секций в которых равномерно/не равномерно будут распределяться сгенерированные элементы.
В секции Свойства элемента задается структура свойств элемнета
В секции Значения полей и свойств производится настройка значений, которыми будут заполнены поля и свойства элементов.
После запуска генерации остается следить за полосой состояния текущей генерации элементов
После завершения будет указано сообщение о успешной генерации указанного числа элементов
скрипта для генерации элементов
Для больших каталогов, которые необходимо распределять по секциям просмотр списка элементов состоящий из 10-20 эл. уже будет не допустимо велик. И единственной рекомендацией в данной ситуации может стать только распределение элементов по секциям.
Тоже думали, что всё будет хорошо.
Вы, Евгений, создайте миллион элементов (100 подразделов), а затем попробуйте их удалить. Потом расскажете о впечатлениях
Зареклись после этого хранить в инфоблоках такой объём данных.
Мы перенесли все данные просто в таблицу, без Битрикса. И всем порекомендую при работе с такими массивами данных обходиться без инфоблоков.
А удалять мы решили потому, что без настройки "Совместный просмотр разделов и элементов" работать слишком неудобно.
Так что я вам рекомендую поставить disclaimer под ссылкой на скрипт генерации элементов. А то ведь карму могут подпортить, те, кто сгенерирует себе миллиончик тестовых элементов.
Мы перенесли все данные просто в таблицу, без Битрикса. И всем порекомендую при работе с такими массивами данных обходиться без инфоблоков.
Зачастую проблемы с производительностью на проектах с таким объемом сводятся к ошибкам допущенным на этапе проектирования или на этапе реализации.
Очевидно что в Вашем случае имеет место одна из указанных проблем
Видимо вы говорите об этапе проектирования самой системы Битрикс )))
Я веду речь об административном интерфейсе. Никакой публички. Создаём миллион элементов для теста, как вы советуете, а потом пытаемся удалить.
Останутся ли потом желающие ставить такие эксперименты...
Возможно, компромисное решение может быть в создании мастера такого автообработчика - пусть он по расписанию в фоне лопатит некое задание, ночью - посильнее, днем послабже, чтобы не "вешать" сайт.
Недавно оптимизировал проект. Чистил старье. Порядка 250 тыс. элементов удалил. Вручную через админку. Железо у нас старое. Удалял по ночам. За неделю справился
Инфоблоки, как интерфейсная надстройка над структурой БД - вещь замечательная, но универсальность требует ресурсов, как не крутись.
есть такой проектик как экзист.ру ну думаю тут многие о нём слышали... так вот я не так давно делал аналог этого проекта только на битриксе и под украину ..
база данных содержит на данный момент порядка 50 млн. записей в 5 инфоблоках
в админку зайти в просмотр листинга не реально
но вот с выборками проблем нет... тоесть выборка в 10-100 элементов в публичной части работает отлично
правда индексы я руками расставлял
к чему я это всё... а к тому, что хранение в инфоблоках такого объёма на самом деле не такая уж и проблема... главное чтоб руки из нужного места расли... только вот для клиента пришлось писать отдельный интерфейс редактирования элементов в котором групировка отключена.. именно групировка в запросе вешает админку
Так что, проблемы есть. А то, что вам пришлось дописывать интерфейс редактирования элементов - это вы считаете нормальным? По-моему, такие вещи должны быть в коробке, а не чтобы каждый клиент заново писал.