Question

Задача: реализовать загрузку на сайт в каталог данных из csv файла + прикрепление картинок в публичной части, то есть для клиентов, которым не дан доступ в админку.

На данный момент сама по себе задача решена:
1) Файлы csv + картинки загружаются в 1 zip архиве
2) Архив распаковывается
3) Сначала обрабатываются построчно данные из csv файлов
4) Наконец подгружаются кратинки к элементам
То есть все работает.

Проблема: в том, что при всем при этом уж больно много запросов возникает даже для небольших файлов с данными.

Собственно вопрос: кто какие способы оптимизации предложит?

На данный момент используется:
1) Для добавления нового элемента ($Element содержит сразу и PROPERTY_VALUES):

Код
$el = new CIBlockElement; $ID = $el->Add($Element);

2) Для обновления элемента:
Сначала для обновления свойств

Код
foreach($ElementProps as $PropCode=>$Value){   CIBlockElement::SetPropertyValues($ElementID, $IBlock["ID"], $Value, $PropCode); }

этот код вызванный для 9 элементов (по 4-5 свойств у каждого) генерирует ~136 запросов.
Затем для обновления самого элемента (и поискового индекса)

Код
$el = new CIBlockElement; $el->Update($ElementID, $Element);

этот код вызванный для 9 элементов ($Element содержит только NAME, ACTIVE, DATE_ACTIVE_TO) генерирует ~535 запросов (! вообще ужас). На сколько я понял, в основном запросы тратятся на обновление поискового индекса... Так как, если его не обновлять (bUpdateSearch=true), количество запросов падает сразу да нескольких штук. Но ведь обновить его нужно, если элемент изменен.
3) Для подгрузки картинок (отдельно для каждого элемента):

Код
CIBlockElement::SetPropertyValues($ElementID, $IBlock["ID"], $arPicts, "IMAGE_MAIN");

этот код вызванный 5 раз (5 элементов) для загрузки 9 картинок (по 2-3 картинки у некоторых) генерирует ~99 запросов.
Итого около 800 запросов для обновления каких-то 9 элементов! А что будет, если подгрузить понадобится 200, 500 позиций?

Важно: используются инфоблоки+, т.е. хранение в отдельных таблицах.

Answer 1

Для начала - пошаговый импорт

Answer 2

Цитата
Кирилл Попов пишет: Для начала - пошаговый импорт

Это ясно - само собой разумеется.
Но вопрос я ставил не "как сделать, чтобы работало", а именно "как оптимизировать" - это самое главное, как сократить количество запросов.

Answer 3

Добрый день.

У меня такой же вопрос как оптимизировать?
Я добавляю 100000 записей из csv файла с помощью функции добавления элемента. За секунду у меня проходит лишь 100 записей. Для проверки сделал то же самое, но через mysql_query() - 10000 записей в секунду.
Получается, чтобы добавить в базу, мне нужно ждать 16 минут. Я их буду добавлять каждый день, в дальнейшем у меня будет и 1 000 000 записей и больше.

Как можно добиться более скоростного добавления?

Answer 4

Помимо этой темы обратился в поддержку продукта, и ответа не последовало.

Поэтому отвечу сам.

1. Добавление ускоряется в 3-4 раза если удалить модуль поиска. Затем добавляю элементы $el->Add($Element) с bUpdateSearch = false. Минусы: - теряем модуль поиска, скорость добавления все равно не устраивает. Сойдет, если добавлять по 50-100 элементов за цикл.

2. Если элементов больше 50000 лучше вообще не использовать добавление битрикса. Выход из ситуации - свои таблицы + mysql_query или чтение из файлов. Это будет работать в десятки и сотни раз быстрее. Лично поверил на 1 000 000 записей.

Answer 5

Александр, я в общем к такому же выводу пришел. А не отвечают судя по всему из-за того, что ответа попросту нет...
Так что из решений и остается только:
1) Обязательное использование пошаговости
2) Добавление с отключенным поиском (bUpdateSearch = false) и затем уже переиндексация
3) Всякие самопальные оптимизации, вроде проверок на измененность, чтобы не обновлять то, что не изменилось
Так пока и делаю... В итоге на загрузку уходит до нескольких минут. А что делать?

Answer 6

Как насчет использования стандартного скрипта импорта. Вроде у него со скоростью проблем нет. Не реализовывал, но, думаю, из публички его можно дернуть.

Answer 7

Иван, да надо будет попробовать. Только он не совсем удовлетворяет. Либо придется переписывать, либо еще что. Функционал-то у него другой. Разве что подсмотреть, как в нем импорт реализован, и использовать оттуда функции в своем скрипте. Хотя я сомневаюсь, что там будет что-то относительно новое. Ну в общем глянем, когда время будет.

Answer 8

Отпишитесь потом, интересно :)

Answer 9

о. сейчас стоит похожая задача, практически идентичная =)
пока тоже отталкивался от $el->Add($Element). Элементов пока порядка 2000, даже на таких объемах оптимизация требуется. Была мысль вставлять записи в базу напрямую подготавливая обширные вставки, пока только мысль.

Иван подал хорошую идею посмотреть в сторону стандартного импорта, тоже сейчас буду его изучать.

Answer 10

Иван, в файле импорта (bitrix\modules\iblock\admin\data_import.php) ничего нет, что могло бы ускорить процесс. Быстрее он не будет работать. Тут та же процедура Add(). У меня грузил в базу в 2,5 раза дольше моей обработки с той же процедурой (моя 4 минуты, скрипт - 9 минут)

Дмитрий Олареско, если будешь использовать стандартный импорт, перепроверь! соответствует ли количество элементов в базе. Случается, что скрипт может не добавить элементы, и при этом в отчете ошибки = 0.

NightCat, если найдешь метод - обязательно пиши, это поможет многим :)