⚠️ Почему после перехода на ORM кастомизации Битрикс24 начинают тормозить
 
ORM делает код чище и удобнее для поддержки. Но вместе с этим появляются новые ловушки, которые могут незаметно съедать память и производительность.
В новой статье на Хабре разобрали самые частые ошибки, которые встречаются в кастомизациях коробочного Битрикс24.
 
Что чаще всего ломает проект:
 
🔹 SELECT *
Самая дорогая ошибка выглядит безобидно.
Если не указать select(), ORM выберет все поля таблицы, включая тяжёлые TEXT и BLOB.
В тестах разница получилась впечатляющей:
— выборка только нужных полей – 0.04 сек
— выборка всех полей – 0.83 сек и почти 500 МБ памяти
 
🔹 fetchAll() на больших объёмах данных
Для CRM, задач и инфоблоков это прямой путь к memory_limit exceeded.
Если данных много, лучше использовать fetch() или читать записи батчами по ID.
 
🔹 Кеширование ORM-коллекций
После перехода на новые ORM-объекты многие пытаются положить EO_Collection в кеш и получают ошибку сериализации.
Правильный путь – это кешировать сам запрос через setCacheTtl().
 
🔹 SQL внутри select
Конструкции вроде SUM() или COUNT() внутри select больше не работают.
Теперь для вычисляемых полей нужно использовать ExpressionField.
 
📌 Главный вывод
ORM – это не просто замена старых GetList().
Красивый код не всегда означает быстрый код. Особенно когда речь идёт о больших объёмах данных и нагруженных порталах.
 

Для разработчиков приложений и кастомизаций это особенно важно: ошибки в запросах быстро превращаются в жалобы клиентов на медленную работу приложения.

 
#Битрикс24 #Разработка #PHP #ORM #Кастомизация #1C-Битрикс