Аудит продуктивності Битрикс: де втрачається швидкість
Повільний сайт Битрикс рідко впирається в одну причину. Швидкість втрачається одразу в кількох місцях: каталог збирає картку товару десятком окремих звернень до бази, шаблон тягне ті самі дані повторно, а оточення залишилося в тому вигляді, у якому проєкт запускали. Користувач бачить одне — сторінка відкривається довго, і він іде раніше, ніж встигає щось вибрати.
Перше вузьке місце продуктивності — каталог. Фільтри, ціни, залишки, торгові пропозиції та властивості збираються окремими запитами, хоча частину з них можна вирішити одним проходом.
Чим ширша вибірка й більше властивостей виведено в лістинг, тим помітніший розрив між холодною та прогрітою видачею.
Друге — надлишкові виклики. Шаблон звертається до одних і тих самих даних кілька разів, зовнішні сервіси опитуються на кожному відкритті сторінки, кеш скидається частіше, ніж змінюється контент. У сумі це зайва робота, яку сервер виконує марно.
Третє — неналаштоване оточення. Кешування, стиснення, віддача статики, параметри бази та черги завдань налаштовуються під конкретний проєкт, а не за замовчуванням. Без цього навіть акуратний код упирається в ресурси сервера, а не у власну логіку.
Діагностика швидкості сайту показує, як ці фактори складаються в пікові періоди: надходить реклама або починається розпродаж, час відгуку зростає нелінійно, і частина замовлень втрачається на рівному місці.
Аудит продуктивності Битрикс розкладає картину на вимірювані ділянки й відповідає на головне питання — що закривається налаштуванням, а що потребує переробки коду.
Що дає оптимізація: вимірювані ефекти для сайту
Оптимізація продуктивності сайту на 1С-Битрикс вимірюється не словом «швидше», а числами до й після. Точки контролю — медіана та 95-й процентиль часу відгуку сторінок, частка запитів, що вклалися в бюджет, і час відновлення після збою.
Знімаємо їх на бойовому контурі під навантаженням, а не на стенді, де трафік не схожий на справжній.
Перший ефект — час відгуку сторінок.
Кешування компонентів і композитний режим, ревізія важких запитів до бази, індекси під вибірки каталогу та перенесення вивантажень у фонові завдання прискорюють відгук у рази: частка сторінок, що вкладаються в бюджет часу, зростає з половини до дев'яти з десяти.
Другий — стійкість до пікового навантаження. Прогрів кешу перед акцією, обмеження паралельних звітів і черга на важкі завдання дають змогу тримати пік у 3-5 разів вище за звичайний трафік: відгук зростає плавно, без обриву й очікування в черзі в користувача.
Третій — зниження часу простою. Моніторинг ключових сценаріїв, відлагоджений регламент відкату та заздалегідь зняті знімки конфігурації переводять відновлення з годин пошуку причини в хвилини за зрозумілим сценарієм.
Четвертий, найцінніший за підсумком: зникає цілий клас відмов — таймаути з'єднань із базою, падіння через пам'ять на імпорті, блокування під час обміну з обліковою системою. Інциденти стають видимі за метрикою раніше, ніж за дзвінком клієнта.
Формати робіт: разова діагностика, впровадження, супровід
Формати відрізняються не глибиною звіту, а тим, що відбувається після нього: залишається діагностика документом чи перетворюється на зміни на стенді.
Ми підбираємо варіант під стан проєкту — якщо сайт просідає на піку, зазвичай достатньо разового аудиту; якщо релізи виходять щотижня, разові заміри майже не дають користі.
| Формат | Коли підходить | Обмеження |
|---|---|---|
| Разова діагностика без правок | Потрібно зрозуміти причину деградації та оцінити обсяг робіт до старту | Закінчується звітом: вузькі місця залишаються на місці, зміни робимо окремим етапом |
| Діагностика з впровадженням | Причина ясна, потрібен результат у межах одного завдання | Потребує вікна на викладку, регресу та повторних замірів на тому самому профілі трафіку |
| Постійний супровід продуктивності | Релізи йдуть часто, навантаження зростає непередбачувано | Потрібні доступи до сервера й моніторингу, пороги оповіщень доведеться підтримувати |
| Розбір перед перенесенням оточення | Планується зміна майданчика, версії платформи або схеми кешування | Прогноз правильний рівно настільки, наскільки профіль навантаження збігається з реальним трафіком |
Навантажувальне тестування вмикаємо точково — коли потрібно відокремити проблему в коді від нестачі ресурсів майданчика. Вибраний формат не блокує інші: разова діагностика легко переростає у впровадження, а воно — в постійний контроль навантаження.
Етапи робіт: від зняття замірів до передачі регламентів
Кожен етап спирається на цифри попереднього — оптимізація навмання виключена. Нижче — етапи оптимізації сайту на 1С-Битрикс і план робіт: від зняття замірів до приймання результатів.
- Збір доступів та інвентаризація. Отримуємо доступ до сервера, адмінки, репозиторію та резервних копій, фіксуємо конфігурацію оточення й склад модулів. Без цього будь-яка правка — ворожіння.
- Зняття замірів. Базова лінія: час відповіді сервера, швидкість генерації сторінок, кількість запитів до бази на типовій сторінці, частка влучань у кеш, вага та кількість статики. Сценарій навантаження повторюємо без змін — інакше порівнювати нічого.
- Пошук вузьких місць. Профілюємо важкі сторінки: повільні запити, вибірки без індексів, зайві компоненти, агенти, які виконуються на кожному зверненні.
- Схема правок. Узгоджуємо, що змінюємо в коді, що в конфігурації сервера, що в кешуванні, з оцінкою ризику та порядком відкату для кожного пункту.
- Впровадження. Йдемо від найбільшого ефекту за найменшого ризику: спочатку кеш і запити, потім компоненти й налаштування оточення. Кожен блок перевіряємо окремо.
- Контрольні заміри. Повторюємо той самий сценарій і порівнюємо з базовою лінією — так видно внесок кожної зміни, а не середня цифра по проєкту.
- Приймання результатів. Фіксуємо підсумкові метрики й передаємо регламенти: карту вузьких місць, список змін, налаштування кешування та моніторингу, щоб деградація не повернулася з найближчим оновленням.
Що залишається у вас: конфігурації, схеми, регламенти
Аудит має сенс лише тоді, коли його результати можна перевикористати без нас. Тому кожен висновок фіксується в артефакті, який ваша команда або інший підрядник застосовує напряму — без відновлення контексту з листування. Пакет документів збирається по ходу робіт і передається цілком на прийманні.
- Документація з оптимізації: що змінено в коді та налаштуваннях, які вузькі місця закрито, які залишилися і в якому порядку їх брати.
- Схема інфраструктури: сервери, балансування, кешування, черги, зовнішні сервіси — з позначкою критичного шляху запиту.
- Регламент обслуговування: періодичність резервного копіювання, порядок оновлення ядра та модулів, перевірка копії відновленням, контроль журналів і місця на диску.
- Карта вузьких місць з пріоритетами: частка часу відповіді на кожній ділянці та очікуваний ефект від кожної правки.
- Налаштовані профілі моніторингу: пороги за часом відповіді, частотою помилок і навантаженням, правила оповіщення відповідальних.
- План відкату: які зміни оборотні, з якої точки відновлюватися і скільки це займає.
- Передача доступів: панель хостингу, адмінка, репозиторій, моніторинг і резервні копії — оформлені на ваші облікові записи, а не на наші.
Приймання йде за цим самим списком: ви перевіряєте, що кожен пункт відтворюється на вашій стороні, і лише потім закриваємо етап. Далі супровід можна вести своїми силами або віддати іншому підряднику — стан системи описано, а не зберігається в головах.
Як зросла продуктивність каталогу: до і після
Каталог з десятками тисяч позицій на 1С-Битрикс у сезонних піках переставав відповідати: розділ збирався по кілька секунд, фільтри йшли в таймаут, частина трафіку втрачалася на відмовах. Розбираємо кейс оптимізації Битрикс з метриками до і після.
Що було вузьким місцем
Основний біль сидів у шаблоні розділу: вибірка товарів ішла по одному запиту на позицію, властивості та ціни підтягувалися всередині циклу, а кеш скидався на кожному обміні з 1С і не розділявся за сторінками пагінації.
Навантаження на базу зростало лінійно з кількістю товарів, а будь-яка зміна ціни обнуляла весь кешований розділ.
Метрики до і після
Правки розбили на шари: пакетні запити замість вибірки по одній позиції, складені індекси під фільтри, роздільний кеш із прив'язкою до сторінки та коректною інвалідацією за подією обміну.
Нижче — зростання продуктивності каталогу за контрольними замірами на тому самому профілі навантаження.
- час відгуку сторінки розділу: з ~4,5 с до 0,8 с;
- частка запитів до бази на одну сторінку каталогу: скоротилася приблизно в 7 разів;
- відмови в пікові години: з 6–8% до рівня статистичної похибки;
- перезбирання кешу після обміну з 1С: з хвилин до секунд.
Через місяць заміри повторили на реальному трафіку — показники утрималися, а імпорт перестав «заморожувати» каталог. Це і є різниця між правкою «на око» та аудитом, де кожна гіпотеза підтверджується заміром до і після.
Що робити, якщо вузьке місце не в коді, а в оточенні?
Розділити «код чи сервер» можна лише замірами, а не здогадками.
Знімаємо профіль на бойовому контурі в момент деградації та розкладаємо час виконання на ділянки: обчислення в застосунку, запити до бази, очікування дискової підсистеми, мережеві виклики до зовнішніх сервісів, віддача статики.
Якщо основну частку займає очікування, а не обчислення, вузьке місце в інфраструктурі — і оптимізація коду дасть косметичний ефект.
Далі перевіряємо гіпотезу порівнянням оточень. Розгортаємо той самий реліз і копію бойових даних на еталонному контурі з іншою конфігурацією та проганяємо однакові сценарії — наповнення каталогу, оформлення замовлення, вивантаження, обмін з обліковою системою.
Якщо на іншому оточенні ті самі сторінки збираються кратно швидше за того самого коду, питання закрито: причина в налаштуванні оточення, а не в застосунку.
У самому оточенні дивимося конкретні місця. Кешування платформи 1С-Битрикс і кеш відповідей на боці веб-сервера: чи не скидається кеш на кожному запиті, чи не вимкнено кеш через права або агенти. Ліміти на пам'ять і кількість одночасних процесів, через які запити стають у чергу.
Пул з'єднань із базою та її параметри: не вистачає робочих потоків, заважають блокування, важкі вибірки йдуть у файлове сортування. Стан диска: черга введення-виведення, синхронні записи в журнали.
І розклад: регламентні завдання, резервне копіювання, обхід індексації, ротація логів — якщо вони потрапляють у пік, картина деградації повторюється за годинами.
Порядок робіт важливий: спочатку підтверджуємо, де саме межа, і лише потім правимо. Інакше переписана ділянка не змінює картину, а регрес доводиться відкочувати.
Кожну правку оточення перевіряємо на копії бойових даних за одними й тими самими сценаріями та порівнюємо заміри до і після — тоді видно, що саме дало прискорення і чи не повернеться вузьке місце на наступному піку навантаження.
Сумніви щодо доступів, строків і правок на живому сайті
Аудит продуктивності 1С-Битрикс не потребує зупинки сайту: заміри знімаємо на бойовому контурі в години низького навантаження, а зміни коду й налаштувань готуємо на копії. Доступи видаються окремим обліковим записом лише на читання — налаштування, журнали подій, копія бази. Права на запис у робочу базу та файли сайту нам не потрібні, після робіт доступ відкликається.
Який обсяг доступів потрібен для аудиту?
Перегляд налаштувань і журналу подій у панелі адміністратора, читання конфігурації та логів на сервері, копія бази. Паролі передаємо через захищений канал і зберігаємо до кінця робіт. Якщо зовнішній доступ заборонено політикою, розбираємо вивантаження разом з вашим інженером.
Чи можна правити сайт без зупинки роботи?
Зміни спочатку перевіряємо на копії та порівнюємо метрики до і після. На бойовий переносимо по одному блоку: шаблони й конфігурації під версійним контролем, тому відкат — це перемикання на попередній стан, а не ручна правка.
Як ідуть правки і скільки займають строки оптимізації?
Спочатку діагностика: вузькі місця ранжуємо за внеском у загальний час відгуку. Правки йдуть ітераціями від найважчої ділянки, кожен крок вимірюваний.
Скидання кешу та перебудова індексів — керована операція: кеш чистимо точково за компонентами, індекси перебудовуємо у фоні, прогрів робимо на копії.
Що буде при зростанні навантаження?
Дивимося, як конфігурація поводиться на піковому трафіку, і фіксуємо поріг, після якого потрібне розв'язання по серверах. Це частина звіту, а не сюрприз у день розпродажу.
Обговоримо ваше завдання: що надіслати для оцінки
Щоб повернутися з оцінкою та планом робіт, а не із загальними побажаннями «прискорити сайт», нам потрібні факти про ваш контур. Нижче — вступні, які найчастіше визначають, де саме втрачається час відгуку; надсилайте те, що є під рукою, решту зберемо разом у розмові.
- адреса сайту та адреса тестового контуру, якщо на ньому є свіжа копія бази;
- версія ядра платформи та перелік підключених модулів, включно із самописними й сторонніми;
- схема розміщення: де працює веб-частина, де лежить база, як вони пов'язані між собою;
- звіти моніторингу та журнали повільних запитів за звичайний тиждень і за період піку;
- опис піків навантаження — розпродажі, розсилки, сезонне зростання — з датами та характером активності;
- що вже намагалися змінювати: кешування, індекси, переписування шаблону — і чим це закінчилося;
- контакт адміністратора та доступи до панелі керування, резервних копій і налаштувань оточення.
Відсутність половини пунктів розмову не гальмує: частину картини наші інженери знімають самі з працюючого сайту, частину — відновлюють за непрямими ознаками.
За підсумками обговорення ви отримаєте перелік вузьких місць з пріоритетами, план робіт за етапами з оцінкою трудомісткості кожного та розуміння, які правки безпечно внести без зупинки сайту. Опишіть завдання оптимізації у зручному вигляді — повернемося з оцінкою та планом.
