Как проверить время отклика сервера

Время отклика, 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 мс, имеет конкретную причину, появившуюся между этими моментами, и знать это ценнее любого опубликованного бенчмарка.

Почему это меняется в зависимости от локации

Расстояние стоит времени, и это нельзя оптимизировать прочь. Каждый круговой путь между клиентом и сервером занимает не меньше времени, чем позволяет физический маршрут, а TLS-соединению нужно несколько круговых путей еще до того, как сможет начаться передача первого байта ответа. Именно поэтому один и тот же сервер может отвечать за 150 мс локально и за 700 мс с другого континента, выполняя при этом ровно ту же самую работу.

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

Поэтому измеряйте оттуда, где находятся ваши пользователи, а не оттуда, где находится ваш сервер, и сравнивайте сопоставимое с сопоставимым. Число без привязки к локации не с чем сравнить.

Когда медленно значит сломано

Иногда медленность - это предупреждение, а не просто вопрос производительности:

• Время отклика, стабильно растущее под нагрузкой, означает, что сервер перегружен. Это заканчивается таймаутами, а не просто медленными страницами.
• Времена, скопившиеся ровно на 30 или 60 секундах, - это таймауты, а не медленность. Что-то вышестоящее не отвечает, и прокси ждет истечения своего лимита, прежде чем сдаться с 504.
• Быстро большую часть времени, но с редкими огромными всплесками обычно указывает на блокировку, cron-задачу, бэкап либо на истечение кэша, когда каждый запрос перестраивает его одновременно.
• Медленно только для авторизованных пользователей означает, что кэш несет анонимный трафик и скрывает под собой по-настоящему медленное приложение.
• Медленно только из одного региона - это проблема сети или CDN, а не приложения, и никакая работа над бэкендом ее не исправит.

Как заметить день, когда все изменилось

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