Як перевірити час відповіді сервера

Час відповіді, TTFB і завантаження сторінки - не одне й те саме число

Їх часто вживають як взаємозамінні, а вони відповідають на різні питання:

• Час з'єднання - це DNS-резолюція плюс TCP-рукостискання плюс TLS-рукостискання. Це переважно відстань і якість мережі, і власний код сервера тут ні до чого.
• Час до першого байта (TTFB) - це момент, коли приходить перший байт відповіді, виміряний від початку запиту. Він включає час з'єднання плюс обробку на сервері: маршрутизацію, запити до бази даних, рендеринг шаблону, будь-які виклики вищих API.
• Час обробки на сервері - це TTFB мінус час з'єднання. Саме цю частину можна виправити у своєму застосунку.
• Час завантаження сторінки - це все разом: HTML, а потім кожне зображення, таблиця стилів, скрипт і шрифт, які завантажує браузер, плюс робота з їх відображення. Сторінка може мати чудовий TTFB і водночас завантажуватися вісім секунд.

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

Вимірювання за допомогою curl

curl показує кожну фазу окремо, що дає змогу відокремити вартість з'єднання від вартості сервера в одній команді:

curl -o /dev/null -sS -w   "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n"   https://example.com/

Усі значення - у секундах від початку запиту, тож кожне включає попередні. Обробка на сервері - це ttfb мінус tls, або мінус connect на звичайному HTTP. Запустіть команду три-чотири рази: перший запит може заплатити за холодний кеш чи нове з'єднання, а одне вимірювання - ще не вимірювання.

Дві речі варто тримати в голові. Це вимірює лише сам HTML-документ, а не сторінку, тож результат завжди виглядатиме швидшим за тест у браузері. І некешована, авторизована чи пошукова сторінка часто разюче повільніша за головну, тож вимірюйте саме ту URL-адресу, яка вам потрібна, а не /.

Що вважати нормою

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

• Менш ніж 200 мс. Швидко. Типово для статичного контенту, теплого кешу або краю CDN, що відповідає напряму.
• 200-500 мс. Нормально для динамічної сторінки, що звертається до бази даних. Цього ніхто не помічає.
• 500 мс - 1 с. Помітно. Зазвичай запит, якому потрібен індекс, некешований шаблон або повільний виклик вищого рівня.
• 1-3 с. Користувачі це відчувають, і пошукові системи це вимірюють. Варто трактувати як дефект.
• Понад 3 с. Щось не так: перевантажений сервер, блокування, тайм-аут вищого сервісу або запит, що виконує набагато більше роботи, ніж повинен.

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

Чому це залежить від локації

Відстань коштує часу, і це не можна оптимізувати геть. Кожен round trip між клієнтом і сервером займає щонайменше стільки, скільки дозволяє фізичний шлях, а TLS-з'єднання потребує кількох таких проходів, перш ніж перший байт відповіді взагалі зможе початися. Тому той самий сервер може відповідати за 150 мс локально й за 700 мс з іншого континенту, виконуючи достеменно ту саму роботу.

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

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

Коли повільно означає зламано

Деяка повільність - це попередження, а не питання продуктивності:

• Час відповіді, що стабільно зростає під навантаженням, означає, що сервер перевантажений. Закінчується це тайм-аутами, а не просто повільними сторінками.
• Значення, що скупчуються рівно на 30 чи 60 секундах, - це тайм-аути, а не повільність. Щось вище за течією не відповідає, і проксі чекає свій ліміт, перш ніж здатися з 504.
• Швидко більшу частину часу з випадковими величезними сплесками зазвичай указує на блокування, cron-завдання, резервне копіювання чи закінчення терміну дії кешу, коли кожен запит перебудовує його одночасно.
• Повільно лише для авторизованих користувачів означає, що кеш обслуговує анонімний трафік і приховує під собою справді повільний застосунок.
• Повільно лише з одного регіону - це проблема мережі чи CDN, а не застосунку, і жодна робота над бекендом її не виправить.

Помітити день, коли щось змінилося

Одне вимірювання показує, що сталося для одного запиту, з одного місця, в один момент, а час відповіді - саме та метрика, що дрейфує, а не ламається різко. Заплановані перевірки постійно вимірюють ту саму URL-адресу з тих самих локацій, зберігають історію, за якою можна вказати на день, коли все змінилося, і сповіщають, коли час перетинає поріг, а не коли скаржиться клієнт. HostTracker виконує ці перевірки з понад 300 точок у 158 містах, тож регіональне уповільнення видно як таке. Запустіть перевірку просто зараз за допомогою інструмента HTTP-перевірки. Якщо сервер швидкий, а сторінка все одно ні, решта відповіді в посібнику як перевірити швидкість сайту.