Время отклика: как мерить, чтобы цифра значила хоть что-то

За неделю в трёх темах назвали три разных отклика по одной и той же площадке: 0.4 секунды, 1.9 секунды и «около четырёх». Площадка одна, замеры мерили разное.

Предлагаю сойтись на общем понимании того, что считать откликом, иначе спор бесконечный. Начну с того, чем меряю сам:

curl -o /dev/null -s -w "%{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}\n" https://example.org/

Пять чисел вместо одного, и каждое отвечает за свой кусок пути.

Разберу эти пять чисел, раз уж тема про порядок.

Числа накопительные, каждое следующее включает предыдущее. Отсюда правило: разницы считать вычитанием. Служба имён съела 31 мс, TCP добавил 47, рукопожатие 86, а дальше полсекунды площадка думала над ответом. Тело ответа пришло быстро, между первым байтом и концом всего 23 мс.

Когда кто-то называет «отклик 0.4», надо сразу спрашивать, это time_connect или time_starttransfer. Разница между ними бывает десятикратной.

а среднее по десяти замерам подойдёт?

Десяти мало, и среднее тут подводит.

Одна подвисшая попытка на пять секунд задирает среднее по десятке так, что оно перестаёт описывать хоть что-нибудь. Берите тридцать замеров минимум и считайте медиану плюс девяностую долю.

Таймаут ставлю примерно вдвое от девяностой доли, тогда медленные страницы доезжают, а мёртвые отваливаются вовремя.

Про хвост согласен. И первую попытку я всегда выбрасываю: имя ещё не в кэше, соединение холодное, число получается не про площадку.

Собрал обвязку, чтобы не считать руками. Тридцать прогонов, вывод сразу с медианой и девяностой долей:

for i in $(seq 30); do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.org/
done | sort -n > /tmp/zamer.txt
awk 'NR==15 {print "медиана", $1} NR==27 {print "хвост", $1}' /tmp/zamer.txt

Файл остаётся на диске, потом удобно сравнивать прогоны между собой.

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

Записал. У меня как раз замер шёл по одной странице, а прогон по двенадцати тысячам.

Раз речь про сбор, скажу главное про замер через посредника: там складываются сразу три времени, и путать их накладно.

Первое: ваша машина до посредника. Второе: посредник до площадки. Третье: сколько площадка думает над ответом. В time_connect попадает только первое, во всём остальном сидят второе и третье вместе.

Отсюда практика. Я делаю два прогона подряд, один напрямую, второй через адрес, и смотрю разницу по time_starttransfer. Разница и есть цена посредника на этом пути. Под длинные прогоны держу приватные серверные адреса с безлимитным трафиком и такой парный замер делаю раз в неделю, чтобы видеть, меняется ли картина.

И обязательно с keep-alive. Без него каждая страница платит за соединение и рукопожатие заново, а числа выходят вдвое хуже реальных.

спасибо, про парный замер вообще не думала

Ещё одно, без чего замер рассыпается: мерить надо на спокойном темпе. Запускаете сто потоков и одновременно меряете отклик, получаете время своей же очереди. Десять соединений максимум, всё остальное на паузе.

И повторять в разное время суток. Ночью и в шесть вечера у одной площадки разница бывает втрое.

Однострочник для тех, у кого уже есть файл с числами:

sort -n zamer.txt | awk '{a[NR]=$1} END {print a[int(NR*0.5)], a[int(NR*0.9)]}'

Свожу, чтобы дальше в спорах ссылаться на формат.

Замер годится, когда указано: какая стадия меряется, сколько было попыток, медиана и девяностая доля, шёл замер напрямую или через адрес, был ли keep-alive и на каком темпе всё это гонялось. Одно число без этих пометок не значит ничего, и три разных отклика из соседних тем как раз тем и объясняются.

Свой набор по той площадке выложу отдельно, там тридцать попыток по каждому из вариантов. Всем спасибо, тема получилась полезнее, чем я рассчитывал.