«А сколько пользователей выдержит наш сервис?»
Вопрос звучит просто, но каждый раз ставит в тупик. Его задают на демо, на встречах с заказчиками, менеджеры, иногда даже сами разработчики.
Когда‑то, ещё в школьные годы, я читала журнал «Хакер» и мечтала, как было бы здорово «ломать серверы» и находить их слабые места.
Теперь я занимаюсь этим вполне законно — через нагрузочное тестирование. И, честно говоря, это одно из самых приятных занятий в моей работе.
Видеть, как система реагирует на рост нагрузки, оптимизировать запросы, отслеживать поведение метрик в реальном времени — это настоящее инженерное удовольствие. Ведь за каждой цифрой стоят реальные пользователи, для которых важно, чтобы всё работало быстро и стабильно, даже в пиковые моменты.
Тем не менее, многие команды избегают нагрузки.
«Мы уже проверяли это в начале проекта — зачем снова?»
«Сложно, долго, не для нас.»
«Сделайте отчёт, главное чтобы красиво смотрелось.»
А иногда — просто страшно увидеть, как система покажет себя в реальных условиях.
На самом деле всё гораздо проще. Главное, понимать ключевые метрики и уметь смотреть на них не как на сухие цифры, а как на отражение реального опыта ваших пользователей.
RPS (Requests Per Second): сколько запросов - не значит сколько пользователей
RPS - одна из базовых метрик производительности. Она показывает, сколько запросов в секунду обрабатывает система под нагрузкой. RPS — это не пользователи, а именно запросы. Один пользователь может за считанные секунды отправить десятки запросов:
открыть страницу (HTML + API + изображения),
обновить данные без перезагрузки (AJAX, WebSocket),
вызвать фоновые процессы (автообновление, аналитика, логирование событий).
Почему важно учитывать именно RPS? Пользовательская активность непредсказуема: «онлайн 500 человек» почти ничего не значит без понимания, сколько запросов они реально создают. Сервисы перегружаются не количеством пользователей, а объёмом их активности.
RPS помогает измерить нагрузку на backend, базу данных, очереди сообщений, сторонние API - именно там чаще всего кроются узкие места.
Latency и Response Time: про что "время ответа" и почему оно обманчиво
Времяотклика — на первый взгляд, самая очевидная метрика. Запрос ушёл — получили ответ сервера. Записали, измерили. И график красивый получили: «200 мс» — и вроде бы хорошо. Но если копнуть глубже, оказывается, даже здесь легко себя обмануть.
Чем эти две метрики отличаются друг от друга:
Response Time — это полное время от отправки запроса до получения полного ответа.
Latency — это только задержка между отправкой запроса и получением первого байта ответа от сервера.
В тестировании приложений чаще смотрят именно на Response Time, потому что он отражает «пользовательский опыт в целом». Однако ориентация только на «среднее» Response Time приводит к ложному чувству безопасности.
Например, среднее время ответа по системе — 200 мс. Но это ничего не говорит о тех случаях, когда сервис «проседает» под нагрузкой, и пользователь попадает в самый медленный хвост распределения.
Что важно запомнить: Response Time даёт общую картину. Latency помогает при глубокой технической диагностике.
Но для оценки реального UX одних этих метрик мало.
Про те самые медленные 5%, из-за которых пользователи злятся
Среднее время ответа — это как «средняя температура по больнице». Она может быть комфортной, но это ничего не говорит о том, как себя чувствует конкретный пациент.
С веб‑сервисами та же история: для кого‑то страница загрузилась мгновенно, а у кого‑то — зависла на несколько секунд. И проблема не в «глобальных сбоях», а в тех самых единичных случаях, которые всегда прячутся в хвостах статистики. Чтобы увидеть эти проблемы, нужны метрики P95 и P99:
P95 покажет, сколько времени укладываются 95% запросов.
P99 — про те самые «долгие» 1% запросов.
Чем дальше P95 и P99 отстают от обычных значений, тем выше риск, что пользователи начнут замечать лаги, подвисания и «странности» в работе сервиса.
P99 показывает "критические" случаи - именно они формируют негативный пользовательский опыт в пиковые моменты нагрузки. Эти хвосты нельзя игнорировать при анализе производительности.
Ошибки случаются. Всегда
Нормальная система под нагрузкой неизбежно даёт ошибки. Это естественно. Поэтому важно не их наличие как таковое, а контекст:
Где именно появляются ошибки.
В каких сценариях.
При какой нагрузке.
Как быстро их становится слишком много.
Какие ошибки встречаются чаще всего:
500 Internal Server Error - бэкенд не справился.
504 Gateway Timeout - кто-то слишком долго думал.
429 Too Many Requests - система сама защищается от перегрузки (rate limiting).
Connection errors - сеть, балансировщик или вообще очередь запросов в панике.
Что действительно важно при изучении ошибок в вашей системе:
Ошибки начинают расти экспоненциально при увеличении нагрузки? Значит, нашли узкое место.
Ошибки 429 срабатывают слишком рано? - Проверьте лимиты и политику rate limiting.
Ошибки появляются уже при малой нагрузке? - Это тревожный сигнал.
Ошибки в нагрузочном тестировании - естественное явление, которое показывает, что система работает на пределе своих возможностей. Это не всегда критично. Но если ошибок становится слишком много, или они начинают появляться раньше, чем ожидается, - это уже сигнал о реальных проблемах в архитектуре или конфигурации.
Как правильно интерпретировать результаты и не попасть в ловушку цифр
Сначала - о главной ошибке. Очень легко зациклиться на "средних показателях" и красивых отчётах. Особенно если перед релизом менеджеры настаивают: "Сделайте, чтобы в отчёте всё выглядело прилично".
Например, у вас получилось "среднее время отклика - 300 мс". Что это значит на деле:
Кто-то получает ответ за 100 мс.
А кто-то - ждёт 5 секунд и злится.
И именно эти случаи потом приводят к жалобам и потерям клиентов.
Что действительно важно при анализе результатов:
1. Сравнивайте не только цифры, но и их динамику. Важно понять, как система ведёт себя при увеличении нагрузки. При каких RPS начинается рост времени отклика? С какого момента появляются ошибки? Насколько плавно или резко ухудшается производительность?
2. Ориентируйтесь на SLO (Service Level Objective) - соглашение о том, какой уровень производительности считается приемлемым для бизнеса и пользователей. Это конкретные цифры, которые определяют: насколько быстро должен отвечать сервис, сколько процентов запросов можно считать "успешно обработанными", какие задержки ещё допустимы.
3. Следите не только за ошибками, но и за деградацией откликов. Ошибок может быть мало, но если задержки растут - это сигнал о перегрузке. Замедление без ошибок - самая коварная проблема, которая легко проскальзывает мимо отчётов, но ощутима для пользователя.
Как анализировать результаты глубже:
1. Сравнивайте профили нагрузки: легкая, средняя, пиковая. Важно понимать, как ведёт себя система при "нормальной" и "чрезвычайной" активности.
2. Отдельно анализируйте критические сценарии: авторизация, оплата, поиск. В них даже небольшое замедление сильно влияет на UX и бизнес-метрики.
3. Учитывайте влияние внешних сервисов. API третьих сторон могут быть бутылочным горлышком, даже если ваша часть работает быстро.
Заключение
Нагрузочное тестирование - это про данные и про умение их правильно читать.
Каждая метрика показывает свою часть картины:
RPS отвечает за общую нагрузку на систему.
Latency и Response Time помогают понять, насколько быстро сервис реагирует.
P95, P99 раскрывают слабые места, которые видит пользователь.
Ошибки 5xx, 429 и другие сигнализируют о перегрузке и сбоях.
Все эти показатели важны, но их ценность раскрывается только в контексте сценариев использования, ожиданий пользователей, и целей бизнеса.
Нагрузочные тесты позволяют заранее оценить, как система справится с настоящей нагрузкой и насколько стабильным будет пользовательский опыт.