Аудит - ИнтерВолга завдає удару у відповідь

1. Недостатні навички програмування і знання 1С-Бітрікс
2. Відсутня або відключено кешування компонентів
3. помилки верстки
4. Проблеми з картинками
5. Проблеми зі скриптами
6. Низький рівень безпеки системи
7. Чи не налаштований сервер
8. Чи не налаштоване автоматичне резервне копіювання
9. Що можна копіювати і як?
10. Резервна копія сайту
11. Резервна копія сервера
12. Виконання агентів на хітах, а не CRON. Відправка пошти по 1 листу на хіт.
13. Чи не видалені невикористовувані модулі
14. висновок

2016 був урожайним на технічні аудити складних інтернет-магазинів. Практично всі звернення були пов'язані з повільною роботою сайту. Це типова проблема сайтів на 1С-Бітрікс, які активно допрацьовуються декількома командами або були зроблені криво, на швидку руку.

В ході аудиту ми перевіряємо:

1. Налаштування програмного забезпечення на сервері (веб-сервер, база даних, кешування)

2. Вихідний код проекту і взаємодія з базою даних

3. Роботу сайту під навантаженням

Ці кроки дозволяють знайти і усунути джерело повільної роботи.

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

Недостатні навички програмування і знання 1С-Бітрікс

У 1С-Бітрікс є свої правила розробки. У них описані особливості роботи системи і те, як потрібно з нею працювати. Практично у всіх проблемних проектах, ми зустрічаємо відступу від правил або їх недотримання, які призводять до помилок і проблем продуктивності.

Поширеність: Дуже висока, зустрічається повсюдно

Ознаки: SQL-запити в файлах сторінок, шаблонах, запити в циклах

Критичність: Висока

Наслідки: помилки логіки, постійні повтори помилок, високе навантаження на рівному місці, повільна робота

Ця поширена проблема виникає з двох причин: погано організований процес розробки і недостатня кваліфікація розробника.

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

Чому дорого супроводжувати?

Завдання які потрібно просто "зробити" стають завданнями "розберися, придумай рішення яка не зламає все що є і зроби".

Чому падає швидкість?

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

Наприклад, на всіх сторінках сайту потрібно вивести меню, пункти якого відповідають тематичним принципом каталозі. Швидке, але погане рішення - в шаблоні сайту викликати CIBlockElement :: GetList () і в циклі обернути в верстку отриманий результат.

Час виконання завдання таким способом - 15 хвилин. Однак тепер на кожен хіт відправлятиметься запит до бази даних. Бітрікс не зможе його кешувати і такий запит буде створювати навантаження. А якщо програміст не передасть в параметри ID Інфоблоки, запит буде виконуватися ще довше. Начебто дрібниця, а на ділі +0,1 сек. до часу генерації кожної сторінки, на сервері з погано налаштованої базою даних. Правильне рішення - використовувати стандартний компонент bitrix: menu. Таке рішення займе не набагато більше часу ~ 30 хвилин, але не буде сповільнювати сайт.

Є кілька способів виявити подібні проблеми: профілювати код за допомогою XDebug або XHprof і перевіряти вихідний код сайту вручну, читаючи код шаблонів, компонент і модулів.

Вартість усунення цієї проблеми сильно залежить від кількості помилок. В середньому, на інтернет-магазин йде 20-40 годин виправлень поганого стилю кодування.

Відсутня або відключено кешування компонентів

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

Поширеність: Дуже висока, зустрічається повсюдно

Ознаки: В режимі налагодження виводиться повідомлення про нульовий розмірі кешу

Критичність: Дуже висока

Наслідки: Повільна робота, високе навантаження

Багато сайтів на Бітрікс наполовину складаються зі стандартних компонентів. Вони відповідають за роботу з базою даних, обчислення і відображення результату в публічній частині. Всі стандартні компоненти мають хороший вбудований механізм кешування і можливість його включення / відключення. Ми часто зустрічаємо повільні сайти, на яких відключено кешування стандартних компонентів.

У складних проектах не завжди вистачає можливостей стандартних компонентів. В цьому випадку розробники змінюють не тільки шаблон а й службові файли, або створюють свої компоненти. Наприклад, наш проект club.alfabank.ru повністю складається з нестандартних компонентів. Тому що завдання складні, навантаження на сервер велика, можливості стандартних компонентів надлишкові і створюють додаткове навантаження.

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

Проблема виявляється стандартною перевіркою Бітрікс "монітор продуктивності".

Включення кешування стандартних компонент займає пару хвилин. Усунення проблем в нестандартних або кастомізованих компонентах займає від 4 до 8 годин. Однак, іноді виправлення неможливо і доводиться заново програмувати компонент.

помилки верстки

Сторінка може завантажуватися довго не тільки через проблеми в серверному коді (back-end). Швидко згенерувала сторінка може містити помилки верстки: зображення не оптимального розміру, підключення JS-файлів з повільних зовнішніх серверів і т.д.

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

Поширеність: середня

Ознаки: Сайт завантажився, але інтерфейс не працює кілька секунд

Критичність: Висока

Наслідки: Користувач бачить сайт спотвореним, пошукові системи вважають сайт поганим

Подібні помилки ми знаходимо за допомогою webpagetest.org і developers.google.com/speed/pagespeed/insights/

webpagetest.org показує як завантажується сторінка в різних містах і країнах і дає детальну статистику про те що гальмує процес.

Google pagespeed insights відразу виводить список проблем на сторінці, які потрібно виправляти.

Якщо забути про помилки HTML, інші проблеми можна розділити на 2 великі групи: Проблеми з картинками і проблеми зі скриптами.

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

Неоптимізовані картинки невідповідного розміру.

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

Проблеми зі скриптами

Підключення скриптів з "далеких" зовнішніх серверів.

Щоб завантажити файл браузер витрачає час на пошук установку з'єднання з віддаленим сервером і тільки потім починає завантажувати файл. Чим далі сервер від клієнта, тим довше встановлювати з'єднання.

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

Неправильне підключення скриптів.

Відвідувач сайту не може взаємодіяти зі сторінкою, поки не будуть завантажений HTML-код.

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

В 1С-Бітрікс є налаштування, які дозволяють не тільки переміщати JS в кінець сторінки, а й об'єднувати їх.

Однак, ці функції працюють, тільки при правильному підключення файлів:

В інших випадках, галочка ніяк не вплине на швидкість завантаження сторінок.

Обсяг робіт по усуненню проблем сильно залежить від кількості виявлених помилок. В середньому, проблеми вирішуються за 4-10 годин, проте, в нашій практиці був випадок, коли рішення зажадало 40 годин роботи front-end і back-end розробників.

Низький рівень безпеки системи

Якщо ви не бачите проблем безпеки, це не означає, що їх немає. Мало хто перевіряє свій сайт вбудованим в Бітрікс "сканером безпеки" після розробки або доопрацювання сайту.

Поширеність: середня

Ознаки: зовнішні відсутні

Критичність: Висока

Наслідки: Зловмисники і конкуренти можуть отримати доступ до сайту

Вбудований "сканер безпеки" дозволяє виявити багато різних проблем:

1. Уразливості на кшталт SQL-injection, Cross-Site Scripting і т.д., які дозволяють зловмиснику отримати доступ в адмінку

2. Файли сесій інших проектів, які дозволять користувачеві авторизуватися на одному з ваших сайтів і отримати доступ до іншого (в рамках одного хостингу).

3. Зневадження, яка виводиться на сторінках публічної частини

4. Службові файли, доступні за URL. До службових файлів відносяться скрипти для відновлення сайту з резервної копії. Такий скрипт може бути запущений зловмисником і доставить масу неприємностей.

Це далеко не повний перелік проблем, які ми знаходимо в проектах. Однак, їх усунення дозволяє захистити сайт і бізнес.

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

Обсяг робіт по усуненню проблеми рідко перевищує 4 годин.

Чи не налаштований сервер

Якщо у вас хороший сервер, це не означає, що сайт спокійно переживе "чорну п'ятницю" . При плануванні рекламної кампанії вам потрібно знати, яке навантаження може обробити ваш сервер. Багато хто помилково вважає свій сайт надійним, швидким і ВІДМОВОСТІЙКО, якщо він витримує кілька тисяч відвідувачів на добу.

Поширеність: висока

Ознаки: сайт працює повільно

Критичність: Висока

Наслідки: Перевантаження сервера, втрата позицій в пошукових системах через простій

Налаштування веб-сервера нагадує задачу щодо розстановки кас в супермаркеті.

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

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

Всі теоретичні розрахунки ніщо, якщо не зробити експеримент і не перевірити, скільки відвідувачів / запитів одночасно може обслужити ваш сайт. Для цього виконується тестування навантаження.

ИнтерВолга проводить тестування навантаження проектів. Під час тестування ми плавно збільшуємо кількість одночасних запитів до сервера і спостерігаємо за витратою ресурсів. Як тільки сервер перестає справлятися з навантаженням, він починає видавати помилки відвідувачам.

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

Обсяг робіт з налаштування сервера і проведення навантажувального тестування 16-40 годин.

Чи не налаштоване автоматичне резервне копіювання

Люди діляться на тих хто робить резервні копії і тих, хто ще не почав це робити.

Поширеність: висока

Ознаки: Остання резервна копія створена більше 1 тижня назад

Критичність: Висока

Наслідки: Катастрофа

Недостатньо робити резервні копії, їх потрібно регулярно перевіряти. Неперевірена копія = відсутність резервної копії.

Що можна копіювати і як?

Якщо сайт дійсно великий (десятки ГБ), його база даних постійно змінюється, резервне копіювання стає проблемою. В інших випадках це проста, досить швидка процедура.

Резервна копія сайту

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

Резервна копія сервера

Якщо сайт працює на виділеному сервері, або він більше 5Гб, або на тому ж сервері зберігається корпоративна пошта і щось ще, потрібно створювати резервні копії всієї файлової системи сервера.

Для автоматичного резервного копіювання і перевірки копій, ми використовуємо Bareos. Особливості його роботи ми опишемо в одній з наступних статей.

Вартість настройки резервного копіювання сервера і подальше адміністрування 8000 руб. / Місяць. Послуга надається в рамках адміністрування і цілодобової підтримки сайтів на бітрікс.

Виконання агентів на хітах, а не CRON. Відправка пошти по 1 листу на хіт.

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

Ознаки: Непостійне час генерації сторінок

Критичність: Середня

Наслідки: Повільна робота сайту

У Бітрікс є вбудованих механізм для виконання службових процедур, він називається "Агенти". Всі процедури, які вимагають виконання у фоновому режимі зберігаються в списку і чекають своєї черги.

Бітрікс і всі сайти на PHP влаштовані таким чином, що без зовнішнього впливу вони знаходиться в "вимкненому". Чи включаються в міру необхідності, для відповіді на запит користувача. Один запит = один запуск системи. Це означає, що сайт не може включиться сам і вивантажити каталог.

У Бітрікс є 2 режиму запуску агентів: на хітах і по CRON. Якщо агенти виконуються на хітах, то при кожному зверненні користувача до сайту, Бітрікс перевірятиме список службових процедур і виконувати одну з них. Поки процедура не виконається, користувач не побачить сторінку сайту.

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

Налаштування займає не більше 30 хвилин.

Чи не видалені невикористовувані модулі

Чим більше модулів в системі, тим довше инициализируется ядро ​​платформи і довше завантажується будь-яка сторінка.

Ознаки: Повільно завантажуються порожні сторінки

Критичність: Низька

Наслідки: Повільна робота сайту

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

Список модулів доступний в розділі Адміністрування на сторінці Настройки> Модулі.

Ми рекомендуємо відключати невикористовувані модулі.

висновок

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

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

Оцініть статтю:

• 31.05.2017
• Сергій Горєлов