Дело в том, что у нас проект разделен по серверам, на одном сервере крутится php, на другом сервере полноценный MySql. Общая локальная сеть. То есть данные от MySql в PHP приходят по сети. Как только мы разделили по серверам работу сайта столкнулись с очень долго работой создания индексов. Виной этому, при создании индекса $index->continueIndex(); происходит циклическая беготня по элементам и формирования для отдельно каждого индекс. В итоге мы получаем огромное количество запросов к MySql и задержку из-за работы протокола сети TCP. Если бы, во время индексации не производить обмен данными с PHP, и уменьшать тем самым количество запросов, было бы гораздо быстрее и красивее.
Поясню на примере: Сейчас создание индекса занимает: Elements: 124 Query count: 4912 Time: 9.2134962081909 сек. Было до разъединения PHP и MySql в секундах 2.91 s при том же количестве элементов и количестве запросов.
Я прекрасно понимаю, что это наша проблема, что мы решили разделить, но теоретически ваш код тоже можно было бы оптимизировать. Даже у вас в документации и рекомендациях четко написано придерживаться правила - не делать запросов в цикле, однако сами нарушили свои рекомендации: https://dev.1c-bitrix.ru/learning/course/?COURSE_ID=32&LESSON_ID=3594
public function continueIndex($interval = 0)
{
if ($interval > 0)
$endTime = microtime(true) + $interval;
else
$endTime = 0;
$indexedCount = 0;
if ($this->lastElementId === null)
$lastElementId = $this->storage->getLastStoredElementId();
else
$lastElementId = $this->lastElementId;
$elementList = $this->getElementsCursor($lastElementId);
while ($element = $elementList->fetch())
{
$this->indexElement($element["ID"]); <-----------
$indexedCount++;
$this->lastElementId = $element["ID"];
if ($endTime > 0 && $endTime < microtime(true))
break;
}
return $indexedCount;
}
public function indexElement($elementId)
{
$element = new Element($this->iblockId, $elementId);
$element->loadFromDatabase();
$elementSections = $element->getSections();
$elementIndexValues = $this->getSectionIndexEntries($element);
foreach ($element->getParentSections() as $sectionId) <-------------
{
foreach ($elementIndexValues as $facetId => $values) <-------------
{
foreach ($values as $value) <-------------
{
$this->storage->addIndexEntry(
$sectionId,
$elementId,
$facetId,
$value["VALUE"],
$value["VALUE_NUM"],
in_array($sectionId, $elementSections)
);
}
}
}
foreach ($elementIndexValues as $facetId => $values)
{
foreach ($values as $value)
{
$this->storage->addIndexEntry(
0,
$elementId,
$facetId,
$value["VALUE"],
$value["VALUE_NUM"],
empty($elementSections)
);
}
}
}
В этом случае необходимо собрать все элементы в кучу, обработать что надо, и потом разом воткнуть в MySql Спасибо за внимание, возможно учтете это в разработке.
Было бы очень удобно, если появилась бы возможность сортировки свойств при создании/редактировании элементов по типу "drag and drop". Сейчас нужно переходить в настройку формы редактирования. Сделайте как в Битрикс24 у лидов и счетах.
Хотелось бы видеть код свойства инфоблока при редактировании элемента как минимум на этапе разработки, т.к. приходится каждый каждый раз лезть в настройки ИБ, чтобы взять код свойства. Можно это сделать в квадратных скобках напротив каждого свойства.
Если коротко - двух параметров для сортировки не всегда достаточно. Еще хотелось бы управлять сортировкой через глобальный массив, подобно тому, как это происходит с FILTER_NAME.
Все что для этого нужно - добавить еще один параметр в компонент, например "SORT_NAME" и несколько строк кода, примерно так:
В форме редактирования элемента инфоблока поля "Дата начала активности" и "Дата окончания активности" имеют календарики, и в этих календариках можно выбрать в т.ч. время.
В случае, если мы в списке элементов используем инструмент группового редактирования, во-первых, сами поля маленькие, так что для установки времени нужно прокручивать содержимое поля, что неудобно, во-вторых, у календариков нет ввода времени. Но поле-то одно и то же, и логично ожидать от него одинаковых возможностей по вводу.
Предлагаю к календарикам полей "Дата ... активности" добавить возможность установки времени.
Сейчас, чтобы реально скопировать элемент инфоблока с картинками, нужно их заново подгружать в форму (а если их нет на компьютере, ещё и предварительно загружать).
Например, у меня есть инфоблок с мастер-классами. Вся необходимая графическая информация уже есть у старого мастер-класса, осталось только нажать "копировать" и поменять дату проведения. Да, по логике так. В реальности же надо искать эти же фотографии и заново их загружать в том же порядке в соответствующие поля.
Считаю, что функционал несправедливо подрезан. Сделайте так, чтобы при копировании привязки к файлам оставались. Понимаю, что при этом возможно придётся копировать сами прикреплённые файлы, но это хотя бы логично. Если надо подгрузить новые, пользователь CMS может это сделать, а сборщик мусора потом удалит неиспользуемые файлы.
Отказаться от разделения на каталог и новости, и назвать компоненты - "элементы инфоблока", "элемент инфоблока детально" и т.д.
В настройках компонентов есть логичный параметр - "Свойства", позволяющий выбрать, какие свойства элементов нужно выводить. Они попадают в DISPLAY_PROPERTIES. Тем не менее, в результирующем массиве присутствует массив PROPERTIES со всеми-всеми свойствами... Зачем создавать лишние выборки?!
Ну и косвенный момент - новые дефолтные шаблоны каталога наворочены страшно, написаны совершенно нечитабельным кодом. Кастомизировать их - это значит стереть весь код и написать с нуля. Надо как-то по-нормальному сделать дефолтные шаблоны, чтобы их можно было понять кому-либо, кроме их создателя...
п.1 - разделения нет. если компоненты с разным функционалом. п.2 - не можем из-за сохранения совместимости п.3 - работаем над этим, ждите ближайших обновлений.
Описанное ниже актуально, когда заполнять приходится большое количество элементов.
По шагам. Картинка 1: Добавляем новый элемент - заполняем имя, индекс сортировки (10). Жмем "Сохранить и добавить"
Картинка 2: Справа от заполненных полей появляются строки с той информацией, которая была заполнена в предыдущем элементе. Строки серого цвета, что бы не отвлекать внимание и не полные, что бы не занимать место. Перед строками кнопки, позволяющие заполнить тем, что было в предыдущем элементе. Актуально, если в новом элементе меняется лишь часть строки (например 1-ый элемент "iPhone 3g 5s 16gb", а второй элемент "iPhone 3g 5s 32gb"). Для индекса сортировки хорошо тем, что не нужно помнить, какой он был в предыдущем элементе.
Картинка 3: Жмем кнопки описанные выше, поля заполняются значениями предыдущего элемента. Редактируем и жмем "Сохранить и добавить".
Картинка 4: Серые строки теперь показывают данные элемента сохраненного последним. Индекс сортировки вычисляет шаг, если он был изменен в предыдущих двух элементах. Например в первом и втором сортировка была 10 и 20, то на третьем предложит вариант "30".
Клиент очень матерился - промазал и снес огромный раздел каталога, и его ни о чем не спросили, никакого алерта не вылетело... Пришлось восстанавливать бэкап.
У меня огромный каталог с миллиономами элементов и десятками тясячами разделов. Очень часто приходится переносить разделы\элементы из одного раздела в другой. Очень неудобно искать нужный раздел в выпадющем селекте дерева разделов( Как-то надо удобнее сделать.