Приглашаем опытного программиста для поддержки и развития крупного информационного портала на Битрикс.
|
Приглашаем опытного программиста для поддержки и развития крупного информационного портала на Битрикс.
|
|
|
|
|
|
Спасибо, заменили на предложенный вами механизм, надеюсь получится ускорить.
Пока, к сожалению, не сильно заметно, т.к. выбирается большой объем данных. Какие еще могут быть варианты оптимизации для подобных структур данных? |
|
|
|
|
|
Во-первых, можно не перебирать все для получения ID продавцов, а заполнять массив по мере получения информации о товарах. Во-вторых, не пытались оптимизировать запросы в GetList? Приведите пример кода - возможно, сумеем помочь. Ну и как вариант, попробуйте сменить структуру инфоблоков.
Не надо сверлить зубы через задний проход дрелью от Сваровски
|
|
|
|
|
Так и есть, однако есть сложность: товары выводятся в зависимости от фильтров, а фильтры должны содержать все значения из базы (наименования, марки и т.д.). Приходится делать отдельный запрос для получения значений фильтров и только потом выводить сами товары. Разумеется, почти все массивы заполняются в запросе получения значений фильтров. Основная проблема, как я вижу, это большой объем информации. Чтобы выбрать данные из инфоблока, на 1 запрос тратится порядка 1-5 секунд, в зависимости от общей загрузки сервера (без кеширования). Это очень долго. Сейчас в базе порядка 50 тыс записей (в общем - ерунда), но почему-то тормозит. А как можно изменить структуру ИБ, т.е. какие тут есть пути оптимизации?
Это код запроса для получения значений фильтров, далее идет второй запрос, собственно, выборка значений предложений. |
|||||
|
|
|
|
Была такая же ситуация, но с бОльшим количеством связей с другими инфоблоками. Пробовали по-разному. В итоге - использовали чистый SQL. Ну, скажем так, пратически чистый, немноо зависящий все-таки от переданных компоненту параметров.
крыша этого дома - пуленепробиваемая солома.
|
|
|
|
|
|
Виталий Оборин верно обрисовал подход.
Проблему с подобными симптомами решали аналогичным его совету способом. Имхо, подобные вещи получаются из-за невозможности с помощью API битрикса сделать JOIN нескольких ИБ и вернуть результаты в рекордсете.
Поэтому и приходится делать запрос к первому ИБ, собирать ключи внешние и делать второй запрос к связанным ИБ что бы вытащить нужные данные. Ну или обходить в цикле и на каждой итерации дёргать. К примеру, стандартная функция по приводу внешней связи к читабельному виду (Название + URL) делает запрос с помощью всё того же GetList и если вы в цикле для своей выборки делает подобные вещи, то получите по одному запросу на каждый шаг цикла. Хотя можно обойтись одним или несколькими запросами. Очень интересно узнать менение разработчиков, что именно мешает и мешает ли ввести в классы работы с ИБ возможности джойна на уровне API |
|||
|
|
|
Как вариант - фильтр на ajax попробовать, типа гуглового выпадающего списка фраз.
Вопрос сразу отпадет.
Не надо сверлить зубы через задний проход дрелью от Сваровски
|
|||||
|
|
|
Гадаю, проблема в разработчиках, которые написали неправильный код, или в битриксе, который тормозит и будет тормозить... А как вы решаете вопрос с обновлениями версий битрикса при использовании чистого SQL? Он у вас не связан с другими частями? |
|||
|
|
|
Как это проверить, нигде не нашел? |
|||
|
|
|
В примерах работ я видел сайты Эльдорадо, Банки.ру, Гдеэтотдом, там ведь тоже по большие базы и много выборок из них. Любопытно, как там реализованы эти механизмы? Кстати, заметил, что стандартные компоненты типа фотогалереи, форум и др, работают сравнительно быстро. Возможно, разработчики не учили особенности битрикса при создании компонентов. Где можно об этом почитать? Еще вопрос, насколько принципиально выделять рабочий функционал в компонент или использовать прямо в файле: sitename.ru/service/index.php ? |
|||
|
|
|
|
не сравнивайте сайт эльдорадо со своим, он работает на 4 серверах по моему, используется БД MSSQL или Оракл (у QSOFT можно подробнее почитать что там сделано).
А выход какой для вас - перевестись на инфоблоки 2.0, поставить индексы по полям фильтра, отловить длинные запросы и определить откуда они вызываются, попытаться оптимизировать запросы при помощи стандартных утилит MySQL. Если не поможет - поставить второй сервер только для MySQL, настроить работу двух серверов в связке и смотреть что будет дальше. Была подобная задача, только там не элементов было 50к, а свойств примерно 900к. Мы вышли из ситуации следующим образом - перевели инфоблоки в инфоблоки 2.0, поставили индексы для работы выборки по фильтру, потом отказались от API Битрикса и перешли на прямые запросы. Как вариант, вы можете сделать так - производить запрос один раз, потом сериализовать полученный массив и выводить в дальнейшем его, а не делать запросы к БД.
тел. +7-3852-555-807
WA +79339335399 |
|
|
|
|
если делать так - будет жутко неудобно отслеживать изменения и вносит коррективы. Компонентная модель подразумевает разделение логики работы и шаблона вывода информации на две части. Если от этого уходить - следующий ваш программист будет месяц въезжать в логику работы сайта, и только потом будет вносить какие то изменения. Если для вас - это непринципиально - делайте так, как вам удобно.
тел. +7-3852-555-807
WA +79339335399 |
|||
|
|
|
Поэтому и ищу решения, как это исправить. Интересно, отказ от mySQL в пользу Oracle сильно увеличит производительность? Насчет отдельного сервера базы данных - хорошая идея, будем думать, но все-таки невозможно все время наращивать мощности оборудования, сайт должен работать быстро за счет своей структуры. Или получается, что все упирается в технические ресурсы? Как проверить версию инфоблоков? |
|||
|
|
|
![]()
Любые другие варианты - чистой воды мазохизм, с этим к психиатру.
Не надо сверлить зубы через задний проход дрелью от Сваровски
|
|||||||||||||||
|
|
|
||||||||||||||