Проблеми продуктивності сайтів на «1С-Бітрікс»

Генеральний директор ITSumma

Ми провели більше ста аудитів продуктивності сайтів, і проблеми, які ми знаходимо в проектах, досить типові. У сьогоднішній статті ми розповімо не тільки про ці поширені проблеми, але ще і про цікаві рідкісних ситуаціях, з якими доводилося стикатися.

З 2015 року ми виконуємо офіційну послугу «1С-Бітрікс» - аудит продуктивності сайтів . В рамках аудиту ми не просто аналізуємо настройку і конфігурацію сервера, але також переглядаємо код: переносимо проект до себе на стенд, де вивчаємо що саме можна змінити в коді і конфігурації компонентів так, щоб сайт працював швидше.

Однак спочатку давайте поговоримо про те, від чого взагалі залежить швидкість завантаження сторінок і продуктивність сайту. Існує, на наш погляд, помилкова думка, що всі проблеми швидкості завантаження сайту можна вирішити оптимізацією налаштувань або зміною хостингу. Це дійсно допомагає в разі кількох класичних помилок настройки, які ми розглянемо нижче, однак, основні проблеми найчастіше криються в неоптимальних алгоритмах, настройках «1С-Бітрікс», проблеми з кешуванням.

Пояснюється це досить просто: сучасні процесорні технології досягли піку частоти одного ядра. Що це означає для нас? В умовах, коли один запит виконується на одному ядрі процесора - немає практично ніяких можливостей прискорити час виконання запиту в два рази. Швидше за все, у процесора на вашому сервері вже висока частота і зі зміною сервера вона не стане в два рази вище. Сервери на хостингових майданчиках частіше відрізняються кількістю оперативної пам'яті і кількістю ядер / процесорів, на них розташованих.

Ситуацію можна порівняти зі стійкою кас в супермаркеті - одна каса може обслужити одну людину за певну кількість часу. Існує межа людських можливостей, швидше якого в заданих умовах покупця обслужити не можна. Якщо в процесі покупки касиру доводиться забивати номер кожного товару в касу руками, зміна касира може бути і допоможе, але в два рази швидше покупки оформлятися не стануть. Треба міняти саму процедуру покупки (а в нашому випадку - оптимізувати код). Збільшення числа процесорів / ядер на сервері відповідно порівняно зі збільшенням кількості кас на стійці - одночасно можна обслужити більше покупців, але кожен покупець окремо буде незадоволений.

Таким чином, грамотний аналіз продуктивності проекту включає в себе:

• аналіз коректної настройки сервера, аудит серверної конфігурації і потужностей (раптом все-таки «касир» дуже повільно працює сам по собі - тоді будь-яка процедура буде здаватися нам повільної, і ми не зможемо зрозуміти що ж саме оптимізувати);
• алгоритмічний аналіз проекту, профілювання часу завантаження сторінок, аналіз роботи цих сторінок як з кешуванням так і без нього (аналіз оптимальності процедури покупки на сайті);
• аналіз швидкості завантаження сайту в браузері, оптимальності фронтенда.

Розглянемо ці пункти в подробицях.

Аудит серверної конфігурації

Перш за все, ще до початку аудиту продуктивності ми перевіряємо синхронізацію raid-масиву (віддзеркалення жорстких дисків) і його наявність, а також коректність роботи системи резервного копіювання. Дуже часто один раз налаштовані віддзеркалення і резервне копіювання були після цього перевірені ні разу, а між тим, за нашою статистикою, резервне копіювання ламається раз в місяць. Якщо ви не перевіряли бекапи більше цього періоду - цілком можливо що їх у вас немає (докладніше можна прочитати в статті про організацію резервного копіювання ). Слідом ми приступаємо до аудиту продуктивності - він складається з досить конкретних, але критичних елементів чекліст.

1. Чи розташований сайт на віртуальному хостингу, VPS / VDS, віртуальній машині?

На жаль, в переважній більшості випадків віртуальний хостинг так чи інакше продає клієнту більше апаратних потужностей, що має насправді фізично. Наслідком цього може бути нестача дискової підсистеми в пікові години, може бути нестача процесорного часу. Крім кількох ситуацій ми рекомендуємо використання виділеного сервера на цій апаратній базі для e-commerce проекту, що приносить гроші. Так, різниця вартості між віртуальним і «справжнім» виділеним сервером може становити десятки разів. Однак ця економія не варто того потенційного збитку (як фінансового, так і репутаційного), який може бути нанесений в разі аварії на хостингу.

2. Які версії ПО встановлені на сервері?

PHP молодше версії 5.5 і MySQL версії молодше 5.5 ми рекомендуємо до апгрейду. Важливо: в разі якщо проблеми проекту перш за все пов'язані з кодом - апгрейд PHP не призведе до прискорення сайту. Але якщо код оптимальний і підтримує такий перехід - використання PHP версії 5.5 і вище може призвести до прискорення часу генерації сторінки на 20-30%, а використання PHP7 (в разі якщо проект PHP7-сумісний) - до двократного зростання продуктивності на рівні PHP. Варто пам'ятати, якщо ваша сторінка генерується за 1000мс, з яких 800мс займають неоптимальні запити до БД - навіть дворазове прискорення PHP7 призведе до прискорення лише на 100мс (час відповіді стане 900мс замість 1000мс). Час роботи з базою даних від зміни версії PHP не зміниться.

3. Чи варто оптимізатор PHP-коду?

На даний момент стандартом індустрії і рекомендованим оптимізатором PHP є opcache. Крім абсолютно унікальних випадків використання opcache є обов'язковим. Прекомпіляції PHP-коду, яку здійснює PHP-оптимізатор, прискорює час обробки PHP-скрипта на 80-90%. Оптимізатор PHP займається трансляцією PHP-коду в байт-код, який набагато ближче до машинного. При використанні оптимізатора ця трансляція стає разової процедурою, а при його відсутності PHP виконує трансляцію при кожному запиті.

4. Відключений чи відладчик XDebug?

Отладчик XDebug є популярним модулем серед розробників, призначеним для налагодження коду. Його зручно і корисно використовувати на серверах розробки, але на бойовій машині XDebug уповільнює час виконання коду в два рази. Таку ситуацію ми бачимо досить часто: XDebug залишається запущеним після запуску нового сайту в бій, або ж він залишається встановленим після термінової налагодження на бойовому сервері. XDebug обов'язково треба вимикати.

5. Перевірка engine таблиць в MySQL

Незважаючи на те, що в 2016 році MyISAM вважається застарілим «движком» таблиць, ми зустрічаємо його використання на бойових сайтах. Можливо, причина в перенесенні таблиць з використаної при розробці бази даних, де тип движка не сильно критичний. Можливо на це просто не звернули увагу, а можливо цей тип таблиць використовували з історично сформованих упереджень. У будь-якому випадку для типових задач слід використовувати InnoDB і його похідні. MyISAM за своєю структурою мало чим відрізняється від відомого всім старого формату dbf-файлів, не призначеного для промислового використання в багатокористувацької середовищі. MyISAM часто схильний до блокувань на рівні таблиці (коли один запит сайту заблокує всі інші запити), дуже чутливий до падінь MySQL (аварійне падіння може призвести до критичної втрати даних), насилу піддається резервного копіювання на льоту (резервне копіювання великої таблиці призведе до блокування сайту ). Всіх цих проблем в InnoDB немає, проте, він повинен бути коректно налаштований.

6. Коректність настройки InnoDB

Перш за все мова йде про розмір buffer pool - внутрішньому кеші MySQL. У разі якщо оперативної пам'яті досить, а розмір даних невеликий, ми рекомендуємо виставити buffer pool вище, ніж розмір директорії з даними (таким чином кешуватися всі дані). При аудиті добре допомагають інструменти Percona Tools - в нашому блозі є оглядова стаття . Тема тюнінгу MySQL досить об'ємна, докладніше про неї поговоримо в одній з найближчих статей.

7. Моніторинг роботи сервера, перевірка використання swap-а

Жодна оптимізація не допоможе, якщо сервер лежить під величезним навантаженням через наплив відвідувачів, або процесам не вистачає пам'яті і частина їх вивантажено в swap. Swap-файл працює з жорсткого диска, який в будь-якому випадку в сотні разів повільніше оперативної пам'яті. Мало того, зазвичай процеси настільки активно використовують оперативну пам'ять, що в разі вивантаження її на диск - дискова підсистема сервера негайно досягає своєї межі і сайт перестає відповідати. На сервері повинен стояти моніторинг: в момент «гальм» важливо розуміти, що стало їх причиною - сильне використання дискової підсистеми, нестача серверного CPU, а може бути взагалі вичерпання пропускної спроможності мережевого інтерфейсу?

Аудит коду проекту

Переконавшись в тому, що проблеми сайту не пов'язані з проблемами хостингу (або вирішивши їх), ми переходимо до аналізу коду. Дуже часто може здаватися, що в спочатку грамотно спланованому проекті проблем з кодом бути не може. З нашого досвіду, проблеми виникають не в результаті одноразово досконалої помилки, а з ряду змін, кожне з яких призводить до невеликого уповільнення роботи сайту, і сумарно ці проблеми призводять до великої затримки.

Перш ніж займатися пошуком проблемних місць в коді, потрібно розуміти які інструменти ви будете використовувати для цих пошуків, яку інформацію вони дають і яка у них ступінь застосування.

Для початкового аналізу довгих місць сайту ми використовуємо монітор продуктивності 1С-Бітрікс. Знаходимо найбільш відвідувані з довго відповідають сторінок - їх прискорення призведе до відчутного зниження навантаження на сервер. Якщо не враховувати популярність сторінки, а звертати увагу тільки на швидкість відповіді, то можна витратити час на оптимізацію сторінки, яку запитують раз на місяць і яка не створює реального навантаження.

Монітор продуктивності включається в такий спосіб: в адміністративній панелі сайту вибираємо в меню «Налаштування» -> Панель продуктивності -> Кнопка «Тестувати продуктивність». Після закінчення збору даних у вкладці «Розробка» буде таблиця з усіма відвідуєте сторінками і часом їх генерації.

Після того як ми вибрали довгі сторінки на окремому сервері (ми знаємо потужності цього сервера, і ми знаємо, що сервер не завантажений) аналізуємо час створення цих сторінок в режимі налагодження, дивимося на час генерації окремих компонентів і розуміємо, на що саме слід звернути увагу в аналізі коду цих сторінок. У перших ітераціях ми перевіряємо як працюють сторінки в режимі з використанням кешування, а в останніх - вивчаємо роботу сайту без кеша. Нерідко сторінки, які відкриваються досить швидко з використанням кешу, без нього починають відкриватися за 30-60 секунд. Здавалося б, ситуація коли кеш закінчився на рідко відвідуваних сторінках не страшна, однак, що прийшов в каталог пошуковий бот може серйозно навантажити сервер, почавши обходити такі сторінки.

Режим налагодження включається безпосередньо на сторінці сайту: в панелі адміністратора необхідно знайти пункт «Налагодження» і в випадаючому меню вибрати пункт «Сумарна статистика». Якщо необхідно перевірити роботу кеша, то додатково відзначте галочкою пункт «Детальна статистика кеша».

У деяких випадках цієї інформації не вистачає - коли деякі частини коду не потрапляють в режим налагодження або коли хочеться детальніше вивчити структуру вкладеності викликів PHP. У таких випадках ми підключаємо модуль профілювання XHProf, який дозволяє відстежити час виконання як всього PHP скрипта, так і вкладених функцій.

Розглянемо використання режиму налагодження і утиліти XHProf на прикладі сторінки каталогу з розділами. Проблема: при включеному кешуванні компонент Bitrix: catalog.section повільно виконується.

Крок 1. Звертаємо увагу, що компоненти не кешируєтся і виконується вкрай повільно. При цьому виконання запитів займає приблизно 16% від часу виконання компонента. Очевидно, що присутні якісь проблеми в реалізації компоненту.

Крок 2. Для налагодження PHP використовуємо XHProf. Обертаємо потрібний нам компонент в код утиліти XHProf.

Крок 3. Оновлюємо сторінку, щоб XHProf зібрав потрібні нам дані.

Крок 4. Відкриваємо сторінку з даними XHProf.

Крок 5. Знаходимо підключення потрібного нам компонента Bitrix: catalog.section. Відкриваємо і бачимо наступне:

Виконання шаблона компонента Bitrix: catalog.section займає 1,5 секунди, це велика частина часу генерації всієї сторінки.

Крок 6. Йдемо далі по стеку викликів і знаходимо виклик скрипта result_modifier.php. Якщо пройти далі, то можна побачити призначену для користувача функцію, в якій виконуються запити:

Власне, ця надбудова у вигляді result_modifier.php є причиною повільної генерації. Таким чином, виправивши проблему коду в даній надбудові, можна вирішити проблему з повільною завантаженням сторінки з розділами каталогу.

Давайте тепер пройдемося по найчастішим проблем, які ми зустрічаємо в результаті аудиту конфігурації 1С-Бітрікс.

Аудит конфігурації «1С-Бітрікс»

Неправильна структурна організація Інфоблоки

Мабуть, це найбільш поширена проблема - зустрічається в 90% проектах. Коли усі товари «складають» в один інфоблок. У такого Інфоблоки накопичується велика кількість властивостей всіх товарів, це загрожує великими вибірками і повільним імпортом. Розглянемо на прикладі абстрактного спортивного магазину, у якого в асортименті одяг, лижі, велосипеди (і у кожного виду товарів свої властивості). Властивості товарів потрапляють в один інфоблок, велосипеди отримують властивості лиж та одягу (і, відповідно, навпаки - дані види товарів отримують властивості велосипедів). Уявіть, скільки «надлишкових» властивостей накопичується, якщо категорій товарів у магазина багато.

При цьому одного разу ми зіткнулися з протилежною проблемою: у проекту була правильна структура Інфоблоки, але також було багато агрегують вибірок (новинки, акції, хіти). Вийшло, що замість одного запиту в «довгий» інфоблок для генерації вибірки відправлялося за запитом в 50+ швидких Інфоблоки і потім ще відбувалося їх поєднання в коді. Через це компонент в цілому став працювати повільніше. Так що якщо проекту необхідна така функціональність, то треба розробляти запасний план - створювати окрему таблицю в базі даних (робити «денормализация» структури Інфоблоки), або через зовнішню агрегацію, або щось ще.

«Самопісний компоненти»

Часто зустрічаються ситуації, коли програмісти і веб-студії використовують сторонні, «авторські» компоненти, які при цьому не використовують наявні можливості платформи 1С-Бітрікс. Наприклад, самописние «розумні фільтри» не використовують фасетного індекси - це значно збільшує час виконання компонента. Трапляється, що програмісти не вивчають детально встановлюється компонент і не беруть до виду помилки і проблеми, які він додає. Рекомендуємо ретельно аналізувати встановлюються компоненти.

Проблеми із зовнішніми сервісами

Це не пов'язано з самим кодом 1С-Бітрікс, але зустрічається у багатьох клієнтів. Так чи інакше багато сайтів використовують зовнішні сервіси для додаткової функціональності на сайті: оновлення курсу валюти, розрахунок часу та вартості доставки товару, API партнерів і т.п. Коли такий зовнішній сервіс починає довго відповідати - починає довго відповідати і сам сайт. На жаль, багато зовнішні сервіси завжди відповідають довго. Можливий спосіб вирішення проблеми - періодична завантаження даних за завданням через Cron, і краще якщо це буде відбуватися в найменш завантажене час роботи проекту.

Проблеми з фасетного індексами

У більшості випадків невикористання фасетного індексу в розумному фільтрі - це просто недогляд (якщо мова не йде про проблему з попереднього пункту). Фасетний індекс обов'язково необхідно використовувати, він значно прискорює роботу розумного фільтра, і, відповідно, знижує навантаження на процесор і час завантаження сторінки. При додаванні нових властивостей Фасетноє індекс треба перебудовувати, однак, перебудова його в денний час (у піковий час відвідуваності) може привести до замкнутого кола: при відключеному фасетном індексі буде створена фатальна навантаження на сервер, в результаті чого перестворити фасета не вийде. Єдине правильне рішення - перебудова індексу під час мінімального навантаження.

Помилки використання API 1С-Бітрікс

Вібірка властівостей в ціклі после GetList, коли їх можна вібрато в GetList. Сортуваннях и фільтрація засоби PHP вместо использование arFilter и arSort. В API 1С-Бітрікс існує велика Кількість функцій, оптимальних для НАВАНТАЖЕННЯ на сервер. Розробник та патенти знаті ЦІ Функції и вміті їх застосовуваті. Регулярної помилки є, например, Отримання списку товарів и подалі Отримання їх властівостей в ціклі, в тій годину, коли Властивості можна отріматі в основному запіті. Таким чином, например, отримай 100 товарів, ми створюємо додатково 100 Запитів до бази даних для Отримання властівостей. Чи не Варто кож вібіраті товари для їх підрахунку - в API 1С-Бітрікс є для цього спеціальна функціональність. Дивно, але дуже часто ми бачимо як товари вибираються для того, щоб порахувати частина з них по якомусь властивості.

Проблеми при генерації меню

У великих проектах стає проблемою генерація меню (або секцій каталогу) з підрахунком кількості елементів в категоріях / секціях. Виходячи з цієї кількості елементів якраз і будуються вищевказані області. Для оптимізації швидкості роботи проекту ми не рекомендуємо використовувати цю функцію. Докладний кейс був детально розглянутий в співтоваристві розробників Бітрікс .

Ще досить часто спостерігаємо проблеми з доробленими меню. Наприклад, розробники не звернули увагу, що меню не кешируєт висновок шаблону і написали меню з включенням в нього самого популярного товару по кожній категорії. Вийшло, що при перегляді користувачем меню на кожен елемент створюються запити до бази (що, природно, уповільнює роботу проекту). Сам 1С-Бітрікс реалізує дану «кастомную» функціональність через включення компонентів з такими елементами в result_modifier.php.

включений антивірус

Веб-антивірус займається перевіркою сторінок сайту на шкідливий контент, який міг бути доданий в результаті злому / модифікації сторінок. Хоча ця функціональність і корисна, ми, звичайно, рекомендуємо відключати цей модуль, залишивши включеним модуль проактивного захисту - відключення веб-антивіруса може прискорити завантаження сторінки на 100-200 мс.

Приклад завантаження сторінки з включеним антивірусом:

І та ж сторінка з вимкненим антивірусом:

Встановлений модуль компресії

Модуль компресії призначений для хостингових майданчиків, в яких включити компресію на рівні веб-сервера не представляється можливим - в основному на «древніх» shared-хостингах. У разі, якщо gzip-компресію на рівні веб-сервера ви включити можете (а в більшості випадків це можливо) - ми рекомендуємо відключити цей модуль.

Агенти виконуються на хітах

Ще одна історична функціональність, яка дуже часто зустрічається на проектах клієнтів. «Агенти» - регулярно виконуються завдання в 1С-Бітрікс, можуть виконуватися або через традиційний для нас cron, або всередині коду, викликаного призначеним для користувача запитом - цей режим називається «Агенти на хітах». У такому режимі 1С-Бітрікс кожен запит користувача перевіряє чи не настав час виконати регулярну процедуру (наприклад розсилку), і якщо час спрацювало - починає виконувати це завдання. Проблема полягає в тому, що весь час виконання завдання користувач не буде отримувати результат сторінки, а якщо в настройках веб-сервера встановлено обмеження на час виконання скрипта - такий агент ніколи не буде виконано і пошта не піде. «Агенти на хітах» створені для тих майданчиків, де ви не можете поставити регулярне виконання агентів на cron, зараз таких хостингових майданчиків залишилося дуже мало і ми рекомендуємо всім відмовитися від виконання агентів на хітах. Додаткові відомості про активування агентів на крон можна прочитати в статті Миколи Рижоніна и в запису Антона Долганін . До речі, при включенні стенду, на якому ми перевіряємо код проекту, обов'язково першим кроком перевіряємо в MySQL не включені чи агенти на хітах (і чи не виявиться так, що в момент коли ми зайдемо на сайт, ми виконаємо будь-яке регулярне завдання).

Неправильне використання кешування

У багатьох аудити ми стикаємося з ситуацією, коли кешування було відключено в налагоджувальних цілях і більше не включалося - не забувайте включати. Ще був випадок, коли ми в процесі аудиту виявили, що кешування деяких компонентів на сторінці не працює. Нюанс полягав у тому, що після відкриття сторінки файл кеша створювався, а на наступне відкриття вже інвалідіровался. Причиною виявився лічильник перегляду товарів в шаблоні компонента, який при оновленні вносив зміни в інфоблок, що інвалідіровало кеш.

З іншого боку, в ряді самописних компонентів ми зустрічали випадки, коли в кеш завантажувалася дуже велика вибірка даних. Усередині кешу 1С-Бітрікс знаходиться серіалізовані масив, і якщо розмір однієї сутності, що лежить в кеші, стає більше декількох сотень кілобайт (та й цього багато), накладні витрати на вивантаження даних з кешу ставали сильнішими, ніж економія звернення до бази даних.

Проблеми з композитним кешем

Композитний кеш дійсно хороша і зручна технологія, але на диво як часто її використовують некоректно. Найпростіша і дуже часта помилка - збереження ліміту на кеш зі значенням за замовчуванням в 100 мегабайт, це дуже мало.

Ще нерідко в результаті розробки додається новий невеликий компонент, який не підтримує композит, через що композит зі сторінок «злітає». Потрібно стежити за тим, щоб він зберігався.

Сам кеш може віддаватися не тільки з файлів і memcache, але і у вигляді статичних файлів на рівні nginx, проте це використовується дуже рідко. Детальніше про налаштування nginx для роботи з композитом прочитати на сайті курсу розробників Bitrix .

Перевірка клієнтської частини

Зображення без оптимізації

Найчастіша проблема - використання масштабування зображень, а також використання незжатих зображень. Все дуже просто, менше вага картинок - швидше завантаження. Розробники про це прекрасно знають і не грішать такими помилками, але ось клієнти або контент-менеджери дуже часто завантажують величезні, важкі зображення. Треба або підключати автоматичні сервіси та модулі, або вчити користувачів оптимізувати картинки в ручному режимі.

Проблеми з JS / CSS файлами

Тут регулярно зустрічаються дві проблеми: це підключення JS / CSS файлів нестандартним для Бітрікс способом і використання необ'єднаної JS / CSS файлів. Пост в співтоваристві розробників на цю тему .

Найважливіше - неправильне підключення скасовує можливість автоматичного об'єднання JS / CSS файлів, і також скасовує автоматичне забезпечення правильного порядку їх підвантаження (спочатку CSS файли, потім JS-файли).

Кілька разів зустрічалася проблема з надлишком JS - буквально на кожен елемент каталогу навішують подія окремим скриптом. При включенні опції «переносити JS в кінець сторінки» виникала потужна навантаження на сервер.

У зв'язку з цим хочеться зайвий раз нагадати розробникам про необхідність мініфікаціі скриптів, по можливості - асинхронне підключення.

Віддача статики веб-сервером Apache

Як не дивно, але до сих пір ми досить часто зустрічаємо ситуації, коли легковагі статичні файли віддати не через фронтенд у вигляді nginx або йому подібний легкий веб-сервер, а через Apache, з якого часто (особливо при використанні Bitrix Env) лунає динаміка . При цьому кожен такий запит створює додаткове споживання оперативної пам'яті (Apache значно важче) і навантаження на процесор. Ми настійно рекомендуємо переконатися, що віддачею статики займається nginx.

Відсутність компресії на рівні веб-сервера

Тут все просто - статику треба віддавати з gzip-компресією, це періодично упускається, на жаль. Переконатися, що статика віддається з компресією можна, наприклад, тут .

підводімо Підсумки

Значимість швидкості завантаження сайтів зростає: пошуковики готують штрафи в позиціях видачі для повільних сайтів, користувачі карають «рублем» і йдуть до більш спритним конкурентам. Ми хочемо, щоб хороших і швидких сайтів було якомога більше. Використовуйте ресурси хостингу і платформи 1С-Бітрікс грамотно, щоб отримати якісний у всіх відносинах проект, який не соромно розмістити в портфоліо. Сподіваємося, наші рекомендації допоможуть вам у вирішенні проблем продуктивності проекту. І не забудьте поділитися статтею в соцмережах, якщо для вас вона виявилася корисною.