Что такое RPS и время отклика: простое объяснение

В любом отчёте о нагрузочном тестировании два главных числа — запросы в секунду и время отклика. По-английски их часто пишут как RPS (requests per second) и latency или response time. Ниже — что они означают, как связаны друг с другом и с числом посетителей, почему среднее значение обманывает и какие цифры считать хорошими.

Что такое запросы в секунду (RPS)?

Это число обращений к серверу, которые он получает и обрабатывает за одну секунду. Обращение — это любой запрос браузера: сама страница, файл стилей, скрипт, картинка, запрос данных для фильтра каталога.

Важно понимать, что одна открытая страница — это не один запрос. Браузер сначала получает HTML-страницу, а потом запрашивает всё, что в ней указано: стили, скрипты, шрифты, картинки. На типичном сайте одна страница порождает десятки запросов. Часть из них уходит на ваш сервер, часть — на сторонние сервисы: счётчики, виджеты, сети доставки контента.

Поэтому в отчётах различают:

• запросы в секунду — все обращения к серверу, включая статические файлы;
• страницы в секунду — только открытия HTML-страниц, которые сервер собирает для посетителя;
• визиты — сессии посетителей, каждая из нескольких страниц.

Статические файлы сервер обычно отдаёт быстро, а страницы — особенно каталог, поиск, корзина — собирает с обращениями к базе данных. Поэтому 1 000 запросов в секунду к картинкам и 1 000 запросов в секунду к странице поиска — совсем разная нагрузка.

Что такое время отклика и из чего оно складывается?

Время отклика — сколько проходит от отправки запроса до получения ответа. Для страницы его можно разложить на этапы:

1. Поиск адреса сервера (DNS) — по имени сайта браузер узнаёт адрес сервера.
2. Установка соединения, а для HTTPS — ещё и обмен ключами шифрования.
3. Ожидание ответа — сервер получает запрос, собирает страницу и начинает её отправлять. Время до первого байта ответа называют TTFB (time to first byte). Именно этот этап сильнее всего растёт под нагрузкой.
4. Загрузка ответа — передача самой страницы по сети.

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

Почему среднее время отклика обманывает?

Представьте 100 запросов: 95 из них выполнились за 0,3 секунды, а 5 — за 10 секунд. Среднее время — около 0,8 секунды, вроде бы неплохо. Но каждый двадцатый посетитель ждал 10 секунд и, скорее всего, ушёл.

Поэтому время отклика описывают процентилями:

• медиана, или 50-й процентиль (p50) — половина запросов быстрее этого значения, половина медленнее. Так работает сайт для «типичного» посетителя;
• 95-й процентиль (p95) — 95 % запросов быстрее этого значения. Главный показатель в большинстве отчётов: он показывает, каково приходится почти всем посетителям, включая невезучих;
• 99-й процентиль (p99) — 99 % запросов быстрее. Важен для программных интерфейсов (API), которые вызываются много раз за одну операцию, и для крупных сайтов, где даже 1 % — это тысячи людей.

Посетитель за визит открывает несколько страниц, поэтому шанс хотя бы раз попасть в медленный «хвост» у него выше, чем кажется по одному запросу. Это ещё одна причина смотреть на p95, а не на среднее.

Как связаны RPS, время отклика и число посетителей?

Эти три величины связаны простой формулой из теории очередей (её называют законом Литтла):

запросов в работе одновременно = запросы в секунду × время отклика в секундах

Условный пример: сервер получает 200 запросов в секунду, и каждый выполняется 0,5 секунды. Значит, в любой момент сервер обрабатывает около 200 × 0,5 = 100 запросов одновременно. Если у него, например, 50 рабочих процессов, каждый из которых обрабатывает один запрос за раз, остальные запросы будут ждать в очереди — и время отклика вырастет.

С посетителями похожая логика. Посетитель не отправляет запросы непрерывно: он читает страницу, думает, листает. Поэтому:

страниц в секунду ≈ посетителей на сайте ÷ (время между открытиями страниц + время отклика)

Если на сайте 300 человек, и каждый открывает новую страницу в среднем раз в 30 секунд, сервер получает около 10 страниц в секунду. Отсюда важное следствие: «1 000 человек на сайте» — это вовсе не 1 000 запросов в секунду. И наоборот: в нагрузочном тесте виртуальные посетители делают паузы короче, чем люди, поэтому каждый из них нагружает сайт сильнее живого человека. Хороший отчёт это учитывает и пересчитывает нагрузку в понятные «людей на сайте». Подробнее — в статье сколько пользователей выдержит сайт.

Что происходит, когда сервер достигает предела?

Если повышать нагрузку постепенно, картина почти всегда одна и та же:

1. Сервер справляется. Посетителей больше — запросов в секунду больше, время отклика почти не меняется.
2. Рост запросов в секунду останавливается. Сервер обрабатывает столько, сколько может, остальные запросы встают в очередь. Время отклика начинает расти — это и есть точка деградации.
3. Очередь переполняется. Появляются ошибки: 502 (веб-сервер не дождался ответа от приложения), 503 (сервер отказывает из-за перегрузки), 504 (превышено время ожидания), обрывы соединения.

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

Какие ещё показатели встречаются в отчётах?

• Пропускная способность (по-английски throughput) — по сути те же запросы в секунду, но успешно обработанные. Иногда её считают в мегабайтах в секунду — тогда она показывает, не упирается ли сайт в ширину канала.
• Одновременные пользователи (concurrent users, иногда VU — virtual users, виртуальные пользователи) — сколько программ-посетителей работает с сайтом в данный момент теста. Это настройка нагрузки, а не её результат: важно, сколько запросов они создают и как на них отвечает сервер.
• Доля ошибок (error rate) — процент запросов, закончившихся ошибкой сервера, обрывом соединения или превышением времени ожидания (таймаутом). Ответы 404 «страница не найдена» обычно говорят об ошибке в сценарии теста, а не о перегрузке.
• Время до первого байта (TTFB) — часть времени отклика до начала ответа. Хорошо показывает, сколько сервер думает над страницей.
• Индекс удовлетворённости Apdex — число от 0 до 1, которое считают по доле «быстрых», «терпимых» и «медленных» ответов относительно выбранного порога. Встречается в системах мониторинга; удобен, чтобы следить за динамикой одним числом.

Как читать график запросов в секунду и времени отклика?

Откройте графики числа посетителей, запросов в секунду, времени отклика (p95) и ошибок на одной шкале времени и пройдите по ним слева направо:

1. Пока линии посетителей и запросов в секунду растут вместе, а время отклика почти ровное, — сайт справляется.
2. Найдите момент, когда время отклика начало заметно расти. Посмотрите, сколько посетителей было в этот момент, — это практическая вместимость сайта.
3. Проверьте, продолжали ли расти запросы в секунду. Если нет — сервер работал на пределе, и запросы копились в очереди.
4. Посмотрите, когда появились первые ошибки и какие. Если сначала растёт время, а потом появляются 502 и 504, — не хватает рабочих процессов или ответ не укладывается в таймаут. Если сразу появляются 503 или 429, — сработал лимит хостинга или защиты.
5. Найдите в таблице по страницам ту, у которой время отклика выросло раньше всех. С неё и стоит начинать оптимизацию.

Какое время отклика считать хорошим?

Универсальной нормы нет: всё зависит от того, что за страница и чего ждут посетители. Но есть ориентиры:

• В руководстве Google для разработчиков (web.dev) рекомендуется, чтобы время до первого байта (TTFB) у большинства сайтов было не больше 0,8 секунды.
• Для страниц, которые сервер собирает с обращениями к базе данных — поиска, фильтров каталога, — время отклика под нагрузкой обычно больше, чем у закэшированных страниц. Важно, чтобы оно не росло резко вместе с числом посетителей.
• Если у вас есть соглашение об уровне сервиса (SLA) — например, «95 % запросов быстрее 1 секунды», — проверяйте именно его.

Практичный подход — заранее записать критерий успеха для своего сайта, например «при ожидаемом пике p95 не больше 2 секунд и ошибок меньше 1 %», и сравнивать результат теста с ним. Как сформулировать такой критерий, разобрано в статье как провести нагрузочное тестирование.

Как измерить RPS и время отклика своего сайта?

• Без нагрузки время отклика одной страницы покажут инструменты разработчика в браузере (вкладка «Сеть») и сервисы проверки скорости. Но они ничего не скажут о том, что будет при наплыве посетителей.
• Текущую нагрузку — сколько запросов в секунду сайт получает сейчас — покажут журналы веб-сервера и системы мониторинга.
• Поведение под нагрузкой покажет только нагрузочный тест: нагрузка растёт постепенно, а графики запросов в секунду, времени отклика и ошибок строятся на одной шкале времени.

Тестировать под нагрузкой можно только свои сайты или сайты, владелец которых дал согласие. В LoadSure это проверяется перед каждым запуском: права на домен подтверждаются DNS-записью, файлом или мета-тегом. В отчёте есть и вывод простыми словами — сколько человек сайт держит уверенно, — и для специалистов графики запросов в секунду, времени отклика по 95-му процентилю и ошибок по каждой странице.