Чому сервер повільний: діагностика по кроках

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

Крок 1: відокремити сервер від фронтенду

Спершу з'ясуйте, де саме втрачається час: сервер довго формує відповідь, чи браузер довго її малює. Це принципово різні проблеми з різними рішеннями.

Орієнтир простий: якщо час до першого байта великий — справа в сервері, базі або коді. Якщо він нормальний, а сторінка все одно з'являється повільно — проблема у фронтенді: зображення, скрипти, шрифти.

Крок 2: подивитись, чого не вистачає

• Процесор. Постійне навантаження близько до межі означає, що або трафіку більше, ніж тягне тариф, або якийсь процес зациклився.
• Пам'ять. Найнебезпечніший варіант: коли її бракує, система починає вбивати процеси, і сайт падає без видимої причини.
• Диск. Черга до диска — часта проблема дешевих тарифів із повільним сховищем.
• База. Найчастіше вузьке місце саме тут, але виглядає воно як «навантаження на процесор».

Крок 3: типові знахідки

Кількість воркерів PHP «за замовчуванням»

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

База з налаштуваннями з коробки

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

Вимкнений кеш байткоду

Без нього PHP перекомпільовує ті самі файли на кожен запит. Вмикається однією зміною конфігурації.

Один важкий запит

Іноді все впирається в єдиний запит без індексу, який виконується на кожній сторінці. Лог повільних запитів знаходить його за кілька хвилин.

Чого робити не варто

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

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

Практична робота — це оптимізація продуктивності сервера. Суміжне: налаштування Nginx і PHP-FPM, тюнінг MariaDB, моніторинг — щоб бачити проблему до скарг. Якщо гальмує саме магазин, а не сервер, дивіться оптимізацію OpenCart.