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

Уявіть: ви запустили рекламну кампанію, бюджет - кілька тисяч доларів, трафік пішов. І сайт ліг. Не через баг у коді, не через DDoS, а просто тому, що сервер не витримав 500 одночасних відвідувачів. Гроші згоріли, клієнти пішли до конкурентів, а ви сидите і дивитесь на 502 Bad Gateway як на надгробок свого маркетингового бюджету. Знайомо? Сумна правда в тому, що 73% власників сайтів ніколи не перевіряли, скільки навантаження реально витримує їхній хостинг. Вони просто вірять у цифри з тарифного плану. А потім дивуються.

Чому тарифний план бреше вам прямо в обличчя

Хостинг-провайдер пише: "Unlimited bandwidth", "99.9% uptime", "High-performance servers". Звучить солідно. Але спробуйте копнути глибше. Unlimited bandwidth - це як "безлімітний" мобільний інтернет, який після 50 ГБ стає повільнішим за поштового голуба. У хостингу те саме: формально лімітів немає, але є fair use policy, і коли ваш сайт починає реально навантажувати процесор - вас просто обмежують або переносять на ізольований контейнер.

Єдиний спосіб дізнатися реальну продуктивність - протестувати самому. Не вірити рекламі, не читати відгуки на форумах, а взяти інструмент і навантажити свій сервер до межі. Це як краш-тест для автомобіля: краще дізнатися про слабкі місця в лабораторії, ніж на швидкості 120 км/год.

Інструменти, які перетворять вас на руйнівника серверів

Добра новина: вам не потрібно бути DevOps-інженером з десятирічним досвідом. Достатньо знати кілька інструментів і розуміти, що саме вони вимірюють. Ось арсенал, який я рекомендую після років роботи з різними проєктами:

1. Apache JMeter - безкоштовний, потужний, з графічним інтерфейсом. Ідеальний для тих, хто хоче налаштувати складні сценарії: авторизація, кошик, пошук. Мінус - він важкий і сам жере ресурси тестової машини.
2. k6 (Grafana) - сучасний інструмент, сценарії пишуться на JavaScript. Легкий, швидкий, ідеальний для CI/CD-пайплайнів. Мій особистий фаворит для регулярного тестування.
3. Locust - Python-based, дуже гнучкий. Якщо ви пітоніст - це ваш вибір. Масштабується на кілька машин без болю.
4. wrk - мінімалістичний CLI-інструмент для швидких тестів. Коли потрібно за 30 секунд дізнатися, скільки запитів на секунду витримує endpoint.
5. Loader.io - хмарний сервіс, не навантажує вашу машину. Безкоштовний план дозволяє тестувати до 10 000 клієнтів на хвилину.

Що саме тестувати і які метрики не брехатимуть

Помилка новачків - запустити тест на головну сторінку і заспокоїтися. Але головна - це зазвичай закешована статика. Вона витримає і 10 000 запитів. А от сторінка каталогу з фільтрами, пошук по базі, оформлення замовлення - це зовсім інша історія. Саме тут сервер починає потіти.

Ключові метрики, за якими варто стежити:

• Requests per second (RPS) - скільки запитів сервер обробляє за секунду. Падає? Ви досягли стелі.
• Response time (p95, p99) - час відповіді для 95% і 99% запитів. Середнє значення бреше, бо ховає хвости розподілу.
• Error rate - відсоток помилок 5xx. Якщо більше 1% - сервер задихається.
• TTFB (Time to First Byte) - скільки часу мине до першого байта відповіді. Все, що більше 600 мс під навантаженням - червоний прапор.

"Performance testing is not about finding the speed of your system. It's about finding the speed at which your system breaks." - Scott Barber, експерт з тестування продуктивності, автор книги "Web Load Testing For Dummies"

Тестуйте не абстрактні URL, а реальні сценарії користувачів. Відкрив головну, перейшов у каталог, відфільтрував товари, додав у кошик, почав оформлення. Це називається user flow testing, і саме воно показує правду.

Покроковий сценарій: від нуля до першого краш-тесту

Давайте розберемо конкретний приклад з k6, бо він найбільш збалансований для більшості проєктів. Ось що потрібно зробити:

1. Встановіть k6 - на macOS через brew install k6, на Linux через apt або snap. Займає 2 хвилини.
2. Напишіть базовий сценарій - файл test.js, де описуєте HTTP-запити до критичних сторінок вашого сайту. Починайте з 10 віртуальних користувачів на 30 секунд.
3. Поступово збільшуйте навантаження - 10, 50, 100, 200, 500 користувачів. Використовуйте ramping-vus executor, щоб навантаження зростало плавно, як реальний трафік.
4. Фіксуйте точку перелому - момент, коли response time різко зростає або error rate перевищує 1%. Це ваша реальна стеля.
5. Порівняйте з вашими потребами - якщо Google Analytics показує піки в 300 одночасних користувачів, а сервер ламається на 200 - у вас проблема, яку треба вирішувати вчора.

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

Що робити, коли результати вас розчарували

Допустимо, ви провели тест і побачили: сервер тримає 150 одночасних з'єднань, а далі - каскад 502 помилок. Не панікуйте. Це не вирок, а діагноз. І лікування існує.

Перше - перевірте конфігурацію. У 60% випадків проблема не в залізі, а в налаштуваннях. PHP-FPM з дефолтними 5 воркерами? MySQL без query cache? Nginx з worker_connections 512? Ось вам і bottleneck. Часто достатньо збільшити кількість PHP-FPM процесів, додати OPcache (якщо ще не увімкнений) і налаштувати fastcgi_cache - і продуктивність зростає вдвічі-втричі без жодних доплат.

Друге - проаналізуйте, що саме стає вузьким місцем:

• CPU на 100% - занадто важкий PHP-код або відсутність кешування. Рішення: OPcache, Redis, оптимізація запитів.
• RAM закінчується - забагато процесів або витік пам'яті. Рішення: зменшити pm.max_children, перевірити плагіни.
• Диск - повільний I/O - база даних на HDD замість SSD або занадто багато логів. Рішення: міграція на NVMe, очистка логів.
• Мережа - рідко, але буває. Рішення: CDN, HTTP/2, стиснення gzip/brotli.

Третє - якщо тюнінг не допоміг, чесно визнайте: ви переросли свій тарифний план. Час мігрувати на VPS, виділений сервер або хмарну інфраструктуру з автоскейлингом. Це не поразка - це зростання.

Регулярність - це не параноя, а гігієна

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

Мій підхід простий: навантажувальний тест - раз на місяць. Автоматизований, вбудований у CI/CD pipeline. Результати порівнюються з попередніми запусками. Якщо p95 response time виріс на 20% - це тригер для розслідування. Ще до того, як хтось із клієнтів напише скаргу.

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

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