Как измерить время ответа сервера?

Как измерить время ответа сервера? Конечно, для этого можно использовать команду ping. Но у этого способа есть два существенных минуса. Во-первых, очень часто по соображениям безопасности сервера на ICMP-пакеты не отвечают. Во-вторых, практическую ценность такое измерение имеет очень редко. В самом деле, какая посетителю разница, что ICMP-пакеты до сервера и обратно идут 20 миллисекунд, если страница с каталогом товаров все равно генерируется 15 секунд. Дальше мы покажем, как можно вычислить время отклика сервера на примере протокола HTTP с использованием библиотеки cURL.

Библиотека cURL предоставляет следующую информацию о времени выполнения операций:

• CURLINFO_REDIRECT_TIME — общее время, которое потребовалось для обработки всех перенаправлений. Каждое перенаправление в HTTP это по сути отправка запроса и получение данных. Таким образом для каждого перенаправления измерение времени лучше проводить отдельно. В дальнейшем будет предполагаться, что никаких перенаправлений не происходит (максимальное количество перенаправлений установлено в 0).
• CURLINFO_NAMELOOKUP_TIME — время, прошедшее с момента начала выполнения запроса до определения IP-адреса сервера по его доменному имени. Для URL заданных по IP-адресу сервера будет равно 0. В дальнейшем это время нас также интересовать не будет, т.к. оно может сильно зависеть от географического положения пользователя и множества других факторов, которые выходят за рамки данной статьи.
• CURLINFO_CONNECT_TIME — время, прошедшее с момента начала выполнения запроса до установления соединения с удаленным сервером (получение пакета TCP/ACK).
• CURLINFO_APPCONNECT_TIME — время, прошедшее с момента начала выполнения запроса до установления SSL-соединения (в рамках данной статьи рассматривается протокол HTTP без SSL).
• CURLINFO_PRETRANSFER_TIME — время, прошедшее с момента начала запроса до отправки HTTP-запроса.
• CURLINFO_STARTTRANSFER_TIME — время, прошедшее с момента начала запроса до получения первого байта ответа от сервера.
• CURLINFO_TOTAL_TIME — общее время выполнения запроса. Это время помимо прочего ззависит от пропускной способности канала пользователя, т.к. включает в себя время загрузки ответа сервера.

Что же из вышеперечисленного действительно представляет практическую ценность? Казалось бы, это STARTTRANSFER_TIME, но оно включает в себя все сетевые задержки. При переносе серверов или точки проверки это время может сильно измениться, но это не будет означать, что сервера стали хуже работать и дольше обрабатывать запросы пользователей.WEBO Pulsar позволяет измерять это время, и если вам интересно полное время, которое пользователь из конкретной географической зоны тратит на ожидание контента, нужно установить переключатель «Способ вычисления времени ответа» в положение «Полное время запроса» при редактировании проверки.

Временем, которое сервер затратил на генерацию ответа является STARTTRANSFER_TIME – PRETRANSFER_TIME, т.е. время, прошедшее между отправкой запроса и получением ответа. В случае с нулевыми сетевыми задержками это время и будет временем, затраченным сервером на генерацию ответа. WEBO Pulsar позволяет измерять и его. Для этого нужно установить переключатель «Способ вычисления времени ответа» в положение «Время обработки запроса сервером + время доступа».

А что же произойдет, если сетевые задержки ненулевые, как это обычно бывает? В этом случае между отправкой HTTP-запроса и получением его сервером пройдет какое-то время, например, t1. А между окончанием обработки запроса сервером и получением ответа пользователем — еще какое-то время t2. Тогда время, затраченное на генерацию ответа будет вычисляться по формуле (STARTTRANSFER_TIME – PRETRANSFER_TIME) – (t1 + t2). В случае, когда на генерацию ответа требуется значительно больше времени, чем на доставку ответа пользователю это некритично. Но если ваш сервер работает быстро и отдает ответ за 2-4 милисекунды, а сетевые задержки между серверами составляют 50 милисекунд, это может существенно повлиять на результаты проверки. Как же вычислить это самое (t1 + t2)?

В идеале для этого нужно использовать утилиту ping, которая покажет среднее RTT (round trip time — время, прошедшее между отправкой ICMP-пакета и получением ответа, которое будет очень близко к t1 + t2). Но в общем случае утилиту ping использовать нельзя, т.к. сервер может не отвечать на ICMP-пакеты. На самом деле, (t1 + t2) ~ (CONNECT_TIME – NAMELOOKUP_TIME). Почему? Потому что обычно между определением адреса сервера и установлением TCP-соединения нужно лишь отправить TCP/SYN пакет и дождаться TCP/ACK пакета.

На обработку TCP/SYN пакета тратится очень малое количество времени (иначе на сервере возникают серьезные проблемы), поэтому это время практически равно RTT. Если же в процессе установления соединения один из пакетов потерялся (на каком-нибудь из промежуточных узлов), то (t1 + t2) ~ (CONNECT_TIME – NAMELOOKUP_TIME)/2. Если потерялось 2 пакета - то делить нужно будет на 3 и т.д.

Чем больше пакетов было потеряно в процессе, тем меньше точность определения RTT. По умолчанию WEBO Pulsar определяет время ответа именно так. Если вычисленное время ответа оказалось отрицательным, это значит, что установление соединения заняло больше времени, чем обычный обмен TCP-пакетами. В этом случае, WEBO Pulsar предполагает, что для установления соединения понадобилось 2 обмена пакетами и делит (CONNECT_TIME – NAMELOOKUP_TIME) на 2. И так вплоть до 5, т.к. дальнейшее приближение уже не имеет смысла из-за сильного падения точности.

Не стоит забывать, что на любом из этапов RTT может отличаться (иногда достаточно сильно) от среднего. Получить точный результат, не имея доступа к серверу невозможно, но данный метод позволяет получить достаточно неплохие результаты. Именно этот метод, «Время обработки запроса сервером», по умолчанию использует WEBO Pulsar для всех проверок.

Проблемы доступности сайта

Доступность сайта - вещь весьма непредсказуемая. Иногда из дома (или с работы) сайт открывается, а у ваших друзей - нет. Иногда сайт то открывается, то не открывается. Или открывается очень медленно. Установить проблему в каждом конкретном случае бывает сложно, но давайте рассмотрим основные типы этих проблем:

1. Недоступность крупного сегмента сети. В этом случае пользователи из одного сегмента сети не могут получить доступ к сайтам другого сегмента (например, из-за ошибок маршрутизации). Это достаточно легко установить специальными утилитами, но поделать в этом случае обычно ничего нельзя. И проблемы такого уровня (глобального) обычно затрагивают десятки и сотни тысяч сайтов, и решают их очень быстро.

   Здесь остается только сидеть и ждать. И надеяться, что ваши пользователи оказались в той же лодке (в том же сегменте), что и ваш сайт.

2. Недоступность хостера (мелкого сегмента сети). В этом случае проблемы обычно заключаются на стороне самого провайдера (и поэтому могут быть исправлены не столь быстро). Точно установить частоту и характер этих проблем вручную практически невозможно, но относительно легко при использовании средств автоматического мониторинга.

   Здесь необходимо при любом простое больше 10-30 минут писать в техническую поддержку вашего провайдера: может быть, они и не знают, что что-то отвалилось?

3. Большое время ожидания. В этом случае, по факту, сайт работает. И открывается для всех пользователей. Но не все пользователи могут его дождаться :)

   Это тоже можно проверить (серверное время ожидания с помощью WEBO Pulsar, а общее время загрузки - webo.in. Если время создания страниц сайта слишком велико, то стоит применить оптимизационные мероприятия. Иначе будут большие потери среди целевых пользователей.

4. HTTP-ошибки на сайте. Достаточно часто бывает так, что из-за большой нагрузки (или сбоя оборудования хостера) сайт начинает выдавать ошибку (500, 502, 503 или подобную). Отследить такие моменты и вовремя перевести сайт или целевых пользователей тоже можно, но это уже потребует особого внимания.

   Для этой цели (когда, какое время, и с какой частотой) лучше всего подойдет именно WEBO Pulsar. С его помощью вся неказистая «кухня» провайдера выйдет наружу, и вы будете четко знать, что происходит с вашим сайтом.

5. Сбой в работе сайта. Иногда с сайтом (в силу аппаратного сбоя или изменения сетевой конфигурации хостинг-провайдера) происходят незначительные происшествия, которые на доступность прямым образом не сказываются, но часть функционала сайта оказывается нерабочей. Например, перестают обрабатываться запросы к базе данных. Или начинают выводиться отладочные сообщения.

   Отследить такую ситуацию можно только просмотрев сам сайт (или проверив его основной функционал). С помощью WEBO Pulsar вы можете проверить как наличие определенного текста на странице, так и его отсутствие. Это позволяет максимально оперативно отреагировать на проблему.