Бенчмарки хостингу, яким ви довіряєте - і які вам брешуть у вічі

Ви обираєте хостинг за красивими цифрами на лендінгу провайдера. 99.9% uptime! NVMe SSD! 10 Gbit/s порт! Виглядає солідно. А потім ваш WordPress рендерить сторінку 4.2 секунди, і ви дивитесь на ці цифри як на рекламу фітнес-клубу в січні - обіцянки красиві, реальність куди прозаїчніша. Проблема не в тому, що провайдери брешуть. Проблема в тому, що ви не знаєте, як правильно читати бенчмарки, що саме вони вимірюють, а що навмисно залишають поза кадром. Давайте розберемося, які тести справді показують продуктивність хостингу, а які - просто маркетинговий шум.

Що насправді вимірюють популярні бенчмарки

Коли хостинг-провайдер публікує результати Geekbench, sysbench або UnixBench, він показує вам синтетичну продуктивність заліза. Це як тестувати автомобіль на динамометричному стенді і робити висновки про те, як він поводитиметься в тисняві Києва о восьмій ранку. Зв'язок є, але непрямий.

Розберемо найпоширеніші тести і що вони реально показують:

• Geekbench / sysbench CPU - чиста обчислювальна потужність процесора. Корисно для розуміння, наскільки швидко PHP скомпілює ваш код. Але не враховує, скільки ще сусідів ділять цей CPU з вами.
• fio / dd - швидкість дискової підсистеми. NVMe може видавати 3 ГБ/с при послідовному читанні, але ваша база даних робить тисячі випадкових IOPS. Це зовсім інша історія.
• iperf3 - пропускна здатність мережі. 10 Gbit/s порт чудово, але якщо між вашим сервером і користувачем 14 хопів з поганим пірингом - ви цих гігабіт не побачите.
• ab / wrk / siege - навантажувальні тести HTTP. Ось це вже ближче до реальності, але тільки якщо тестувати з географічно релевантних точок.

Головне правило: синтетичний бенчмарк показує потенціал, а не реальну продуктивність вашого проєкту. Потенціал процесора i9 вражає. Але якщо на цьому i9 крутиться 200 акаунтів shared-хостингу - вам дістанеться рівно стільки, скільки залишиться після сусідів.

Маркетинговий туман: три цифри, які вас обманюють

Я спілкувався з десятками адміністраторів, які переносили проєкти з "швидкого" хостингу на буквально дешевший - і отримували приріст. Чому? Бо вони нарешті зрозуміли, які метрики реально впливають на їхній стек, а які просто виглядають привабливо в рекламі.

"Benchmarks are like a drunk looking for his keys under a streetlight - not because that's where he lost them, but because that's where the light is." - Brendan Gregg, автор книги "Systems Performance" та інженер Netflix.

Ця цитата ідеально описує ситуацію. Ми вимірюємо те, що легко виміряти. А не те, що реально впливає на швидкість вашого сайту.

П'ять тестів, які розкажуть правду про ваш хостинг

Замість того щоб довіряти рекламним буклетам, запустіть ці тести самі. Вам не потрібно бути сисадміном - достатньо SSH-доступу та 20 хвилин часу.

1. TTFB з реальної локації. Відкрийте webpagetest.org, оберіть сервер у країні вашої аудиторії, запустіть тест. Time To First Byte більше 400 мс? Ваш хостинг гальмує, байдуже що пише провайдер.
2. MySQL benchmark на вашій реальній базі. Запустіть mysqlslap з 50 одночасних з'єднань. Якщо середній час запиту перевищує 100 мс - база задихається. І це не "нормально для shared".
3. PHP response time під навантаженням. Встановіть Query Monitor (для WordPress) або Blackfire.io і подивіться, скільки часу PHP витрачає на генерацію сторінки. Менше 200 мс - добре. Більше 500 мс - проблема.
4. Disk I/O latency. Команда ioping -c 20 . покаже затримку дискової підсистеми. Менше 0.5 мс для NVMe - норма. Більше 2 мс - щось не так, навіть для SATA SSD.
5. Стабільність під тривалим навантаженням. Запустіть wrk -t4 -c100 -d60s на вашу головну сторінку. Не середній час відповіді важливий, а p99 latency - час, за який встигають 99% запитів. Якщо p99 в 10 разів більший за середнє - сервер "стрибає" і ваші користувачі це відчувають.

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

Прихований убивця: noisy neighbors і ліміти, яких нема в жодному бенчмарку

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

Noisy neighbor effect - це коли інший користувач на тому ж фізичному сервері раптово споживає багато ресурсів. Ваш процесор, диск, мережа - все ділиться. І жоден бенчмарк, зроблений одноразово, цього не покаже.

Що робити? Моніторити стабільність продуктивності протягом тижня. Ось простий рецепт:

• Налаштуйте cron-завдання, яке кожні 15 хвилин запускає curl -o /dev/null -s -w "%{time_total}" https://yoursite.com і записує результат у файл.
• Через тиждень побудуйте графік. Якщо час відповіді "стрибає" від 200 мс до 2 секунд в робочі години - у вас проблема з сусідами.
• Порівняйте робочі дні з вихідними. Різниця більше ніж у 2 рази? Сервер перевантажений, і ваш провайдер продав більше ресурсів, ніж реально має.

Стабільність продуктивності важливіша за пікову швидкість. Сайт, який завжди відповідає за 300 мс, краще за сайт, який іноді відповідає за 100 мс, а іноді - за 3 секунди. Google це знає і враховує при ранжуванні.

Як провайдери маніпулюють тестами (і що з цим робити)

Я не кажу, що всі провайдери - злі маніпулятори. Більшість просто показує найкращий можливий результат. Як фото на сайті знайомств - це ви, але у найвдалішому ракурсі, з ідеальним світлом.

Типові прийоми:

1. Тестування на порожньому сервері. Бенчмарк робиться одразу після налаштування, коли на машині ще немає реальних клієнтів. Через місяць цифри будуть зовсім іншими.
2. Cherry-picking метрик. Показують послідовне читання (де NVMe сяє), замовчують random 4K write (де різниця між провайдерами мінімальна).
3. Тестування зсередини дата-центру. TTFB 15 мс! Так, між двома серверами в одній стійці. Ваш користувач у Львові чи Варшаві побачить 200+ мс мінімум.
4. Агресивне кешування під час тесту. Varnish або Redis, налаштовані так, що тест бʼє виключно в кеш. А перший некешований запит - втричі повільніший.

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

Методологія, яка працює: тестуйте те, що відчувають ваші користувачі

Забудьте на хвилину про серверні метрики. Подумайте про досвід людини, яка натискає посилання на ваш сайт. Їй байдуже на IOPS, версію ядра Linux і кількість CPU cores. Вона хоче побачити контент. Швидко.

Єдиний бенчмарк, який дійсно має значення - це Core Web Vitals у реальних умовах. Не лабораторні дані з Lighthouse (хоча і вони корисні), а польові дані з Chrome User Experience Report. LCP менше 2.5 секунд. INP менше 200 мс. CLS менше 0.1.

І ось що цікаво: іноді хостинг за 5 євро на місяць з правильним налаштуванням видає кращі Core Web Vitals, ніж виділений сервер за 200 євро з конфігурацією "за замовчуванням". Я бачив це десятки разів. Тому що продуктивність хостингу - це не характеристики залізa. Це результат взаємодії залізa, софту, конфігурації, розташування дата-центру і вашого коду.

Наступного разу, коли побачите красиву табличку з бенчмарками на сайті хостинг-провайдера, запитайте себе: а що з цього впливає на мій конкретний сайт, мою конкретну аудиторію, мій конкретний стек? Якщо відповідь "не знаю" - тепер ви знаєте, які тести запустити. І може виявитись, що ваш "повільний" хостинг насправді непоганий. Або що ваш "преміум" - звичайна переплата за маркетинг. Перевіряйте. Цифри не брешуть - брешуть ті, хто їх вибірково показує.