Приглашаем опытного программиста для поддержки и развития крупного информационного портала на Битрикс.
|
Приглашаем опытного программиста для поддержки и развития крупного информационного портала на Битрикс.
|
|
|
|
|
|
Спасибо, заменили на предложенный вами механизм, надеюсь получится ускорить.
Пока, к сожалению, не сильно заметно, т.к. выбирается большой объем данных. Какие еще могут быть варианты оптимизации для подобных структур данных? |
|
|
|
|
|
Во-первых, можно не перебирать все для получения ID продавцов, а заполнять массив по мере получения информации о товарах. Во-вторых, не пытались оптимизировать запросы в GetList? Приведите пример кода - возможно, сумеем помочь. Ну и как вариант, попробуйте сменить структуру инфоблоков.
Не надо сверлить зубы через задний проход дрелью от Сваровски
|
|
|
|
|
Так и есть, однако есть сложность: товары выводятся в зависимости от фильтров, а фильтры должны содержать все значения из базы (наименования, марки и т.д.). Приходится делать отдельный запрос для получения значений фильтров и только потом выводить сами товары. Разумеется, почти все массивы заполняются в запросе получения значений фильтров. Основная проблема, как я вижу, это большой объем информации. Чтобы выбрать данные из инфоблока, на 1 запрос тратится порядка 1-5 секунд, в зависимости от общей загрузки сервера (без кеширования). Это очень долго. Сейчас в базе порядка 50 тыс записей (в общем - ерунда), но почему-то тормозит. А как можно изменить структуру ИБ, т.е. какие тут есть пути оптимизации?
Это код запроса для получения значений фильтров, далее идет второй запрос, собственно, выборка значений предложений. |
|||||
|
|
|
|
Была такая же ситуация, но с бОльшим количеством связей с другими инфоблоками. Пробовали по-разному. В итоге - использовали чистый SQL. Ну, скажем так, пратически чистый, немноо зависящий все-таки от переданных компоненту параметров.
крыша этого дома - пуленепробиваемая солома.
|
|
|
|
|
|
Виталий Оборин верно обрисовал подход.
Проблему с подобными симптомами решали аналогичным его совету способом. Имхо, подобные вещи получаются из-за невозможности с помощью API битрикса сделать JOIN нескольких ИБ и вернуть результаты в рекордсете.
Поэтому и приходится делать запрос к первому ИБ, собирать ключи внешние и делать второй запрос к связанным ИБ что бы вытащить нужные данные. Ну или обходить в цикле и на каждой итерации дёргать. К примеру, стандартная функция по приводу внешней связи к читабельному виду (Название + URL) делает запрос с помощью всё того же GetList и если вы в цикле для своей выборки делает подобные вещи, то получите по одному запросу на каждый шаг цикла. Хотя можно обойтись одним или несколькими запросами. Очень интересно узнать менение разработчиков, что именно мешает и мешает ли ввести в классы работы с ИБ возможности джойна на уровне API |
|||
|
|
|
Как вариант - фильтр на ajax попробовать, типа гуглового выпадающего списка фраз.
Вопрос сразу отпадет.
Не надо сверлить зубы через задний проход дрелью от Сваровски
|
|||||
|
|
|
Гадаю, проблема в разработчиках, которые написали неправильный код, или в битриксе, который тормозит и будет тормозить... А как вы решаете вопрос с обновлениями версий битрикса при использовании чистого SQL? Он у вас не связан с другими частями? |
|||
|
|
|
Как это проверить, нигде не нашел? |
||||
|
|
|
|||