Прискорення сайту на Бітрікс: оптимізація ORM D7-запитів

Оптимізація ORM-запитів D7: як прискорити сайт на Бітрікс

D7 ORM — об'єктно-реляційний маппер нового ядра Бітрікс. Ми, розробники з 10+ річним досвідом, часто бачимо проекти, де один необережний запит перетворює сторінку на 5-секундне очікування. Запит, написаний за 5 хвилин, може робити SELECT * із трьома зайвими JOIN — і на великому каталозі це 500 мс замість 10 мс. Розповімо, як знаходити та усувати такі проблеми.

На практиці ми стикалися з проектами, де після оптимізації ORM-запитів час генерації сторінки скорочувався з 3 секунд до 300 мс. Це реальні цифри — достатньо прибрати N+1 та зайві поля. Не знаєте, які запити гальмують сайт? Замовте аудит ORM-шару — отримаєте звіт із конкретними рекомендаціями.

Як D7 ORM будує SQL і які проблеми це створює?

ORM читає опис таблиці з методу getMap() класу-сутності. Відношення (references) описуються там же. Наприклад, для інфоблоків використовується клас \Bitrix\Iblock\ElementTable, в якому getMap() повертає поля та зв'язки. Якщо ви запитуєте IBLOCK.NAME, ORM додає LEFT JOIN до b_iblock. Це зручно, але надлишково, якщо IBLOCK_ID заздалегідь відомий. Ми рекомендуємо завжди перевіряти згенерований SQL через $query->getQuery().

Що таке N+1 і як його уникнути?

N+1 — класична проблема ORM. При використанні fetchObject() кожен доступ до пов'язаної сутності породжує окремий SQL-запит:

// Погано: N+1 запитів foreach ($elements as $element) { echo $element->getSection()->getName(); // додатковий запит на кожен елемент! } // Правильно: підвантажуємо секції одразу $result = \Bitrix\Iblock\ElementTable::getList([ 'select' => ['ID', 'NAME', 'IBLOCK_SECTION_ID', 'SECTION_' => 'IBLOCK_SECTION.NAME'], 'filter' => ['=IBLOCK_ID' => 5], ]); 

Важливість усунення N+1: на 1000 елементах ви отримаєте 1001 запит замість 1. Зі зростанням навантаження це вбиває продуктивність. Наш досвід показує, що усунення N+1 знижує час завантаження сторінок у 2–5 разів.

Як правильно вибирати поля в select?

Якщо не вказати select, ORM вибирає всі поля з getMap(). Для ElementTable це 20+ полів, включаючи DETAIL_TEXT (тип Text — потенційно мегабайти). Правило: завжди явно задавайте лише необхідні поля.

$result = \Bitrix\Iblock\ElementTable::getList([ 'select' => ['ID', 'NAME', 'PREVIEW_PICTURE_ID', 'DETAIL_PAGE_URL'], 'filter' => ['=IBLOCK_ID' => 5, '=ACTIVE' => 'Y'], 'order' => ['SORT' => 'ASC'], 'limit' => 20, ]); 

Коли використовувати runtime-поля?

Runtime-поля дозволяють додавати обчислювані значення прямо в SQL, без обробки в PHP. Наприклад, отримати ціну зі знижкою:

use Bitrix\Main\Entity; $result = \Bitrix\Iblock\ElementTable::getList([ 'select' => ['ID', 'NAME', 'PRICE_VALUE'], 'runtime' => [ new Entity\ReferenceField( 'PRICE', \Bitrix\Catalog\PriceTable::class, ['=this.ID' => 'ref.PRODUCT_ID', '=ref.CATALOG_GROUP_ID' => new Entity\ExpressionField('PTYPE', '1')], ['join_type' => 'LEFT'] ), new Entity\ExpressionField('PRICE_VALUE', '%s', ['PRICE.PRICE']), ], 'filter' => ['=IBLOCK_ID' => 5], ]); 

Через ExpressionField можна виконувати будь-які обчислення на стороні MySQL — це швидше, ніж постобробка в PHP.

Як працювати з великими вибірками без перевантаження пам'яті?

При імпорті або масовому оновленні не завантажуйте всі рядки в пам'ять:

$offset = 0; $limit = 500; do { $result = SomeTable::getList([ 'select' => ['ID', 'NAME'], 'limit' => $limit, 'offset' => $offset, 'order' => ['ID' => 'ASC'], ]); $rows = $result->fetchAll(); foreach ($rows as $row) { // обробка } $offset += $limit; } while (count($rows) === $limit); 

Для великих таблиць ефективніша курсорна пагінація за ID: filter => ['>ID' => $lastId]. Це прискорює запити при зміщенні вглиб.

Кешування ORM-запитів

D7 підтримує вбудований кеш:

$result = \Bitrix\Iblock\ElementTable::getList([ 'select' => ['ID', 'NAME'], 'filter' => ['=IBLOCK_ID' => 5, '=ACTIVE' => 'Y'], 'cache' => [ 'ttl' => 3600, 'cache_joins' => true, ], ]); 

Кеш автоматично інвалідується при зміні даних через ORM. Якщо ви використовуєте прямий SQL — кеш скиньте вручну.

Порівняння підходів до завантаження пов'язаних даних

Типові проблеми ORM-запитів та їх вирішення

Що входить у роботу з оптимізації ORM-шару

Ми пропонуємо комплексний аудит та оптимізацію ORM-запитів під ключ:

• Аналіз усіх ORM-запитів проекту через SqlTracker та профайлер
• Виявлення зайвих select, JOIN, N+1
• Встановлення та налаштування кеша для повільних запитів
• Рефакторинг складних запитів з runtime-полями
• Оптимізація пагінації та обробки великих вибірок
• Документування змін та навчання вашої команди
• Гарантія на результат — прискорення сторінок не менше 30%

Терміни: від 1 до 2 тижнів залежно від обсягу коду. Вартість розраховується індивідуально — пишіть, ми оцінимо ваш проект.

Процес роботи

1. Аналітика — збір метрик, профілювання поточних запитів
2. Проектування — план оптимізації з пріоритетами
3. Реалізація — внесення змін у код
4. Тестування — перевірка коректності та продуктивності
5. Деплой — викладка та моніторинг

Чому варто довірити оптимізацію нам?

Ми — команда сертифікованих спеціалістів 1С-Бітрікс з 10+ річним досвідом. Виконали понад 100 проектів з оптимізації. Знаємо всі тонкощі D7 ORM і вміємо знаходити вузькі місця, які не бачить статичний аналізатор.

Не відкладайте оптимізацію — замовте аудит ORM-шару вашого проекту. Зв'яжіться з нами — ми підготуємо пропозицію протягом 2 робочих днів.

Wikipedia: об'єктно-реляційне відображення