Два сайти можуть мати однакову відвідуваність і поводитися зовсім по-різному. На одному тисяча людей читає закешовану статтю, а на іншому сотня користувачів одночасно шукає товари, застосовує фільтри й оформлює замовлення. У другому випадку сервер може виконувати значно більше роботи.
Кількість відвідувачів сама по собі майже нічого не говорить про те, скільки ресурсів знадобиться сайту. Навантаження створюють не люди як такі, а запити й операції, які сайт має виконати через їхні дії. Тому для оцінки продуктивності важливі кількість одночасних запитів, запити за секунду (RPS), частка кешованих сторінок, робота PHP, бази даних, сесій та зовнішніх API.
10 000 відвідувань за добу можуть бути легшими за 500 відвідувань за три хвилини
Добова відвідуваність не показує, наскільки важким буде піковий момент. Якщо 10 000 відвідувань рівномірно розподілені на 24 години, сервер отримує відносно спокійний потік запитів. Але після push-сповіщення, рекламної розсилки, акції або публікації блогера кілька сотень людей можуть прийти майже одночасно. Саме ці кілька хвилин часто й визначають, чи витримає система навантаження.
Поряд із користувачами за добу варто дивитися на кількість одночасних запитів (concurrent requests) і RPS: скільки запитів сервер обробляє одночасно та за секунду. Один користувач не дорівнює одному HTTP-запиту: сторінка може завантажувати статичні файли, звертатися до API, запускати AJAX-запити, пошук або операції з кошиком. Частину статики може віддати кеш чи CDN, тому до origin-сервера доходять не всі запити. Бот або crawler теж здатен створити помітне навантаження без зростання реальної аудиторії.
Зіставте графік запитів по хвилинах із часом появи 502/503, зростанням TTFB та запуском рекламних кампаній. Середня цифра за добу тут мало корисна: проблема часто виникає в короткий проміжок, коли запити приходять щільною чергою.
Для сервера перегляд статті й оформлення замовлення – зовсім різні операції
Кешована сторінка може віддаватися без повторного виконання PHP і складних SQL-запитів. Динамічна дія, навпаки, змушує застосунок знову виконувати код, працювати із сесією, звертатися до бази даних і, можливо, чекати відповіді зовнішнього сервісу.
Для звичайної статті ланцюжок може виглядати так:
браузер -> CDN/cache -> готовий HTML
Для кошика, пошуку чи оформлення замовлення шлях часто довший:
браузер -> вебсервер -> PHP/application -> сесія -> база даних -> розрахунки -> відповідь
Якщо додається платіжний шлюз, служба доставки, CRM або сторонній API, сервер може ще й чекати зовнішню відповідь. Тому навіть вільний CPU не гарантує швидку сторінку.
Корисний тест – порівняти TTFB кешованої статті, пошуку, сторінки кошика та особистого кабінету. Якщо статті відкриваються миттєво, а каталог починає «думати» після застосування фільтра, проблема швидше пов’язана з динамічною обробкою, а не з самою кількістю відвідувачів.
Пошук, фільтри, checkout і API: які дії найчастіше створюють навантаження
Найбільше ресурсів зазвичай споживають не перегляди сторінок, а операції, які запускають обчислення, серію SQL-запитів або звернення до зовнішніх систем. Саме їх варто перевіряти першими, якщо сайт нормально працює за спокійного трафіку, але різко сповільнюється під час активних дій користувачів.
- Пошук і фільтри. Пошук у великому каталозі, сортування та комбінації характеристик можуть запускати важкі SQL-запити, особливо якщо бракує потрібних індексів.
- WooCommerce checkout і особистий кабінет. Тут одночасно працюють сесії, кошик, база даних, розрахунок доставки, платіжні модулі та зовнішні API. Персоналізовані дані також складніше кешувати.
- Імпорт, експорт, звіти та cron. Фонові завдання можуть довго займати CPU, пам’ять або I/O і збігатися в часі з користувацьким піком.
- Боти та crawlers. Автоматичні обходи створюють навантаження навіть тоді, коли кількість реальних відвідувачів не змінюється.
Один невдалий SQL-запит інколи створює більше проблем, ніж сотні простих переглядів. Порівнюйте CPU, TTFB, повільні SQL-запити (slow queries) і PHP-процеси (workers) під час конкретної операції. Так легше побачити, який запит або URL насправді створює навантаження.
Високий CPU не означає, що на сайт просто прийшло забагато людей
На графіку CPU – 100%, а відвідуваність майже не змінилася. Це не суперечність: достатньо одного важкого запиту, імпорту, невдалого cron-завдання або активного бота, щоб процесор отримав помітне навантаження.
На практиці тут є два різні випадки. У першому сервер отримує багато легких запитів і справді впирається в доступну обчислювальну потужність. У другому запитів небагато, але кожен коштує занадто дорого. Наприклад, якщо один URL запускає складну вибірку з бази даних, збільшення CPU може лише відтермінувати момент, коли проблема знову стане помітною.
Дивіться не на сам факт «CPU 100%», а на те, що відбувалося в цей час. Зіставте пік із URL в access log, cron-завданнями, імпортом, журналом повільних SQL-запитів, активністю ботів і процесами на сервері. Якщо після вимкнення одного важкого процесу навантаження різко падає, причина була не в кількості людей як такій.
Високий CPU не завжди означає помилку в коді. Якщо застосунок оптимізований, кеш працює, а під реальним навантаженням ядра стабільно зайняті корисною роботою, процесорного ресурсу справді може бракувати.
RAM закінчується не через «відвідувачів», а через процеси, які обслуговують їхні запити
Типова картина під час піку: процесор ще має запас, але сторінки зависають, а в логах з’являються 502 або 503. Одна з причин – процеси, які обслуговують динамічні запити, уже зайняті або вперлися в ліміти.
Оперативна пам’ять витрачається на процеси й дані, а не на абстрактну кількість людей у статистиці. Кожен одночасний динамічний запит може займати PHP worker, а сам PHP-FPM працює поруч із MySQL, Redis, вебсервером, Java або Node.js процесами, якщо вони є в стеку.
Якщо всі PHP workers зайняті, нові запити не зникають – вони чекають своєї черги або доходять до таймауту. Коли запитів стає більше, ніж система може обробити паралельно, зростає черга. Якщо бракує RAM і на сервері налаштований swap, система може почати активніше його використовувати, що зазвичай додатково збільшує затримки.
Під час проблеми варто дивитися на використання пам’яті, swap, кількість активних і максимальних workers, ліміти процесів та error log. Код 502 або 503 сам по собі не доводить, що сервер «слабкий», але поява цих помилок тільки під навантаженням є приводом перевірити чергу процесів, пам’ять і ліміти.
Універсальної формули на кшталт «1 ГБ RAM = 100 користувачів» не існує. Один сайт швидко звільняє worker, інший тримає процес зайнятим через повільний SQL або API. RAM треба оцінювати в контексті конкретного застосунку.
Чому CDN може врятувати тисячі переглядів, але не врятувати checkout
CDN добре знімає навантаження там, де відповідь можна кешувати. Зображення, CSS, JavaScript, статичні файли та частина HTML можуть віддаватися з edge-вузлів без звернення до origin-сервера. За великої кількості однакових переглядів це справді суттєво допомагає.
Але персональний кошик, особистий кабінет, checkout, дані конкретного користувача або актуальний залишок товару не можна бездумно віддати всім із одного кешу. Такі запити часто все одно доходять до origin і запускають серверну логіку.
Через це сайт може чудово витримувати наплив читачів на статті й водночас отримувати чергу на оформленні замовлення. Перевірити межу допомагають cache HIT/MISS, TTFB і кількість запитів до origin-сервера. Якщо більшість важких URL постійно обходить кеш, CDN не усуне вузьке місце в PHP, базі даних або зовнішньому API.
Як за симптомами зрозуміти, куди насправді впирається сайт
Однакова скарга «сайт гальмує під навантаженням» може мати різні причини. Тому симптом варто використовувати як напрямок перевірки, а не як готовий діагноз.
| Симптом | Що перевіряти насамперед |
|---|---|
| Головна швидка, пошук повільний | PHP, SQL-запити, база даних |
| Проблеми лише на checkout | Сесії, БД, платіжний або інший API |
| Увесь сайт падає тільки під час піку | PHP workers, RAM, CPU, ліміти процесів |
| CPU має запас, але відповідь довга | БД, I/O, зовнішній API, блокування |
| Після кешування сайт став значно швидшим | Динамічна генерація сторінок |
| 502/503 з’являються тільки під навантаженням | PHP workers, черга, RAM, ліміти процесів |
Тому дивитися графік «за сьогодні» майже марно. Потрібен саме той інтервал, коли користувачі побачили затримку або помилку. Середній CPU 20% за добу нічого не спростовує, якщо на три хвилини під час акції він упирається в межу. Так само «RAM ще є» не означає, що не закінчилися PHP workers або не завис зовнішній API.
Якщо незрозуміло, з чого почати, відкрийте метрики CPU, RAM та I/O, перевірте PHP workers, повільні SQL-запити, TTFB і час появи 502/503. Якщо TTFB зростає разом із slow queries, перевіряйте БД. Якщо CPU вільний, але відповідь затримується, дивіться I/O, блокування або зовнішні сервіси. Один показник рідко дає повну картину.
Коли більше CPU і RAM допоможе, а коли лише відкладе проблему
Додавати ресурси має сенс тоді, коли вузьким місцем справді стали ресурси. Якщо причина в повільному SQL, завислому API, важкому плагіні, зайвому cron або відсутності кешу, потужніший сервер може просто приховати проблему на певний час.
Порядок дій простіший, ніж здається: спочатку знайти вузьке місце, потім виправити його і повторити той самий тест. Після змін варто порівняти TTFB, CPU, RAM, кількість помилок і RPS. Якщо метрики покращилися, але під реальним піком система все одно стабільно впирається в CPU, RAM чи workers, це вже аргумент на користь розширення інфраструктури.
Якщо код, база даних і кеш уже оптимізовані, але проєкт регулярно отримує короткі піки трафіку, наступним обмеженням може стати сама інфраструктура. Якщо такі піки повторюються, одним із варіантів може бути хмарний хостинг для сайтів зі змінним навантаженням. Але рішення про масштабування варто приймати за піковими метриками, а не лише за прогнозом відвідуваності.
Хмарна архітектура не замінює оптимізацію застосунку. Якщо пошук виконує важкий SQL або checkout чекає проблемний API, масштабування не усуває першопричину. Воно доречне після виправлення програмних вузьких місць, коли навантаження продовжує зростати.
Замість питання «скільки користувачів витримає сервер» поставте п’ять інших
Без опису дій користувачів і архітектури сайту назвати коректну кількість одночасних відвідувачів практично неможливо. Спочатку треба зрозуміти, що саме робитимуть ці користувачі одночасно.
- Скільки одночасних запитів виникає в піковий момент? Не за добу і не за годину, а саме тоді, коли сайт починає гальмувати.
- Яка частина сторінок віддається з кешу? Тисяча cache HIT і тисяча повних запусків PHP – це різне навантаження.
- Які дії звертаються до PHP і бази даних? Пошук, фільтри, кошик, кабінет, API та checkout треба оцінювати окремо.
- Де зараз вузьке місце? CPU, RAM, БД, I/O, зовнішній API, PHP workers або їхня комбінація.
- Що відбувається з метриками під час реального піку? Саме піковий сценарій показує, чи система впирається в ресурси, чи в неефективну операцію.
Якщо на ці питання є відповіді, потреби проєкту вже можна обговорювати предметно з розробником або хостинг-провайдером. Якщо відповідей немає, цифра «N користувачів» буде радше припущенням, ніж технічною оцінкою.
Навантаження створюють не відвідувачі як такі, а дії, які вони змушують сайт виконувати. Тому питання «скільки користувачів витримає сервер» без опису самого сайту майже не має правильної відповіді.