от Пирса Корнуэлла

При рассмотрении производительности веб-сайта термин TTFB — время до первого байта — появляется регулярно. Часто мы видим измерения с помощью cURL и Chrome, и в этой статье мы покажем, какие тайминги могут производить эти инструменты, включая время до первого байта, и обсудим, действительно ли это то измерение, которое вам нужно.

Время с помощью cURL

cURL — отличный инструмент для отладки веб-запросов, который включает в себя возможность измерения времени. Возьмем в качестве примера веб-сайт www.zasag.mn (правительство Монголии) и измерим, сколько времени занимает запрос на его домашнюю страницу:

Сначала настройте выходной формат для cURL в ~/.curlrc:

$ cat .curlrc
-w "dnslookup: %{time_namelookup} | connect: %{time_connect} | appconnect: %{time_appconnect} | pretransfer: %{time_pretransfer} | starttransfer: %{time_starttransfer} | total: %{time_total} | size: %{size_download}\n"

Теперь подключитесь к сайту, который сбрасывает вывод (-o /dev/null), так как нас интересует только время:

$ curl -so /dev/null https://www.zasag.mn
dnslookup: 1.510 | connect: 1.757 | appconnect: 2.256 | pretransfer: 2.259 | 
starttransfer: 2.506 | total: 3.001 | size: 53107

Эти тайминги указаны в секундах. В зависимости от вашей версии cURL вы можете получить больше знаков после запятой, чем в этом примере. 3 секунды — это долго, и помните, что это только для HTML-кода с домашней страницы — он не включает JavaScript, изображения и т. д.

На приведенной ниже диаграмме показано, что каждый из этих таймингов относится к типичному соединению HTTP через TLS 1.2 (настройка TLS 1.3 требует на один круговой обход меньше):

  • time_namelookup в этом примере занимает много времени. Чтобы исключить производительность преобразователя DNS из рисунков, вы можете разрешить IP-адрес для cURL: --resolve www.zasag.mn:443:218.100.84.167. Возможно, также стоит поискать более быстрый резольвер :).
  • time_connect — это трехстороннее рукопожатие TCP с точки зрения клиента. Он заканчивается сразу после того, как клиент отправляет ACK — он не включает время, необходимое для того, чтобы этот ACK достиг сервера. Оно должно быть близко к времени приема-передачи (RTT) до сервера. В этом примере RTT составляет около 200 мс.
  • time_appconnect — это настройка TLS. Затем клиент готов отправить свой запрос HTTP GET.
  • time_starttransfer происходит непосредственно перед тем, как cURL считывает первый байт из сети (на самом деле он еще не читал его). time_starttransfer - time_appconnect практически такое же, как время до первого байта (TTFB) от этого клиента - 250 мс в этом примере. Это включает в себя круговое путешествие по сети, так что вы можете получить более точное представление о том, сколько времени сервер потратил на запрос, вычислив TTFB - (time_connect - time_namelookup), так что в этом случае сервер потратил всего несколько миллисекунд на ответ, остальное время было сеть.
  • time_total сразу после того, как клиент отправил разрыв соединения FIN.

Время с Chrome

Chrome и некоторые другие инструменты тестирования используют для измерений стандарт W3C Resource Timing. В инструментах разработчика Chrome это выглядит так:

Опять же, вот как это отображается на типичное соединение HTTP через TLS 1.2, а также показаны имена атрибутов времени ресурсов:

  • Остановка (от fetchStart до domainLookupStart) означает, что браузер ожидает подключения, например выделение кеша на диске, если есть запросы с более высоким приоритетом, или если к этому хосту уже открыто 6 подключений.
  • Первоначальное подключение, показанное Chrome, — это connectStart и connectEnd. В отличие от таймингов cURL, это включает в себя настройку соединения SSL, поэтому, если вы хотите получить достоверную оценку RTT, это будет Initial connection - SSL. Если существующее соединение используется повторно, DNS-поиск, начальное соединение и SSL не будут отображаться.
  • Запрос отправлен — connectEnd - requestStart, что должно быть незначительным.
  • Как и в случае с cURL, если мы вычтем время рукопожатия TCP из TTFB, мы сможем предположить, сколько времени сервер действительно потратил на обработку (опять же, у нас нет точного времени RTT, так что это приблизительно).

Что мы снова ищем?

Эти измерения, включая TTFB, могут быть полезны при диагностике проблем и могут помочь вам разобраться в конкретной проблеме, но действительно ли они говорят вам о том, насколько хорошо работает веб-сайт? В конечном счете, если вы хотите измерить опыт пользователей, время, необходимое для возврата первого байта некоторого HTML, неэффективно. Веб-страница может содержать сотни изображений, на ней может быть JavaScript и стили, которые необходимо загрузить, прежде чем вы сможете взаимодействовать. Чтобы отразить реальный пользовательский опыт, вам нужно засечь время, пока веб-страница не станет полезной, и провести эти измерения на репрезентативной выборке того, откуда ваши пользователи получают доступ к сайту. И это тема для другого дня :)

Первоначально опубликовано на blog.cloudflare.com 17 октября 2018 г.