performance-requirements

Требования к производительности (Performance Requirements)

📚 20 вопросовПройти тест →
Лекция

Требования к производительности (Performance Requirements)

performance-requirements

Требования к производительности (Performance Requirements)

Введение: очередь в кофейне ☕

Если кофе вкусный, но очередь бесконечная — вы уйдёте.
С продуктом так же: функция есть, но если всё «тормозит», пользователь не дождётся.
Требования к производительности — это про скорость, стабильность и нагрузку.
Они переводят «быстро» в измеримые цифры.
💡 Совет: слово «быстро» ничего не значит без метрики, условий и порога.
✅ Вывод: performance-требования делают скорость проверяемой.

Проблема: «работает, но медленно» ❌

Без требований:
  • скорость непредсказуема;
  • нет понимания, что считать успехом;
  • QA не может проверить результат.
С требованиями:
  • есть метрики (p95/p99, rps);
  • понятно, при какой нагрузке измерять;
  • есть критерии приёмки.
✅ Вывод: без performance-требований скорость — это мнение, а не факт.

Чем помогает и как работает

  • Помогает договориться о чётких целях скорости для бизнеса, разработки и QA.
  • Помогает убрать споры «быстро/медленно» и перейти к цифрам и порогам.
  • Помогает заранее учесть пики нагрузки и снизить риск деградации после релиза.
Как это работает:
  • Шаг 1: определяем ключевые пользовательские сценарии и профиль нагрузки.
  • Шаг 2: задаём метрики и пороги (latency, p95/p99, throughput, error rate).
  • Шаг 3: разделяем фронтенд и бэкенд требования (LCP, API latency).
  • Шаг 4: фиксируем критерии приёмки и инструменты измерения.
  • Шаг 5: проверяем метрики на тестовой и боевой нагрузке.
✅ Вывод: performance-требования превращают скорость из ощущения в проверяемый контракт.

Ключевые термины (простыми словами)

  • Latency (задержка) — время ответа на запрос.
  • Response time (время отклика) — полный путь от запроса до ответа.
  • Throughput (пропускная способность) — сколько запросов в секунду (rps).
  • Concurrency (параллельность) — сколько пользователей одновременно.
  • p95/p99 — процентиль, «сколько времени укладывается 95%/99% запросов».
  • Load profile (профиль нагрузки) — как меняется нагрузка во времени.
  • Performance budget (бюджет производительности) — ограничение по времени/весу.
  • Error rate (доля ошибок) — процент неуспешных запросов.
✅ Вывод: performance-лексика помогает говорить о скорости на одном языке.

Самое важное (must-know)

  • Performance-требование всегда содержит: метрику, условия нагрузки и числовой порог.
  • Среднее время ответа недостаточно: обязательно фиксируйте p95/p99 для критичных сценариев.
  • Latency и throughput — разные оси; указывать нужно обе.
  • Error rate — часть performance-качества, а не отдельная тема «на потом».
  • Frontend budget и API-метрики должны быть согласованы между собой.
✅ Вывод: эти пункты защищают от размытых и непроверяемых формулировок.

1. Метрика + условия + порог

Назначение: сделать требование измеримым.
Простыми словами: скорость должна быть описана так, чтобы её можно было проверить тестом.
Аналогия: «доехать за 15 минут» вместо «быстро доехать».
Пример:
Каталог открывается <=2 сек (p95) при 1000 одновременных пользователях.
🔎 Как это происходит на практике:
  1. Команда выбирает критичный сценарий (каталог).
  2. Фиксирует метрику p95 и порог <=2 сек.
  3. Задаёт условия нагрузки (1000 пользователей).
  4. QA проверяет выполнение на нагрузочном тесте.
Характеристики:
  • ✅ есть метрика (секунды);
  • ✅ есть условие (1000 пользователей);
  • ✅ есть порог (<=2 сек).
Когда использовать: для любого ключевого экрана/эндпоинта.
✅ Вывод: без трёх частей требование не проверяемо.

2. Latency vs Throughput

Назначение: не путать скорость ответа и пропускную способность.
Простыми словами: система может отвечать быстро на один запрос, но не держать большой поток запросов.
Аналогия: скорость курьера vs количество доставок за час.
Пример:
Latency: p95 <= 300 мсThroughput: 200 rps
🔎 Как это происходит на практике:
  1. Отдельно измеряем latency по p95/p99.
  2. Отдельно увеличиваем rps и смотрим, где начинается деградация.
  3. Фиксируем минимально допустимый throughput без роста ошибок.
  4. Балансируем обе метрики под целевой профиль.
Характеристики:
  • ✅ latency = «как быстро»;
  • ✅ throughput = «сколько запросов».
Когда использовать: при описании API и серверной нагрузки.
✅ Вывод: это разные метрики, обе нужны.

3. Процентили (p95/p99)

Назначение: описать не «среднее», а реальное поведение.
Простыми словами: процентили показывают, что происходит у большинства запросов и в медленном хвосте.
Аналогия: не «средняя очередь», а сколько людей уложились в лимит времени.
Пример:
p95 <= 300 мс, p99 <= 600 мс
🔎 Как это происходит на практике:
  1. В мониторинге строим распределение времени ответа.
  2. Смотрим p95/p99 в обычной и пиковой нагрузке.
  3. Если p99 резко растёт, ищем узкие места в БД, кэше или сети.
  4. После оптимизаций повторяем замеры тем же профилем.
Характеристики:
  • ✅ среднее скрывает «хвосты»;
  • ✅ p95/p99 показывают реальную стабильность.
Когда использовать: для критичных потоков (оплата, логин).
✅ Вывод: процентиль — честнее среднего.

4. Профиль нагрузки

Назначение: учитывать пики и провалы.
Простыми словами: производительность должна проверяться в условиях, похожих на реальное поведение пользователей.
Аналогия: расписание транспорта — утренний и вечерний пик.
Пример:
Пик: 200 rps в 19:00–21:00, обычная нагрузка: 50 rps.
🔎 Как это происходит на практике:
  1. Аналитик описывает суточный и недельный профиль трафика.
  2. QA собирает тестовый профиль с пиком и плато.
  3. DevOps проверяет авто-масштабирование под пиковую фазу.
  4. Команда обновляет профиль после релизов и маркетинг-акций.
Характеристики:
  • ✅ нагрузка не постоянна;
  • ✅ пик важнее «среднего дня».
Когда использовать: для публичных сервисов и запусков.
✅ Вывод: требования без профиля нагрузки неполны.

5. Performance budget

Назначение: ограничить «вес» и время.
Простыми словами: фронтенд получает чёткие лимиты, чтобы страница не становилась тяжелее с каждым релизом.
Аналогия: лимит багажа в самолёте — нельзя «перегрузить» интерфейс.
Пример:
LCP <= 2.5 сек, JS <= 200 KB.
🔎 Как это происходит на практике:
  1. Команда задаёт лимиты LCP и веса бандла.
  2. CI проверяет performance budget на каждом PR.
  3. Если лимит превышен, релиз блокируется до оптимизации.
  4. После релиза метрики подтверждаются в продовой аналитике.
Характеристики:
  • ✅ контролирует фронтенд-перфоманс;
  • ✅ помогает держать скорость.
Когда использовать: для пользовательских интерфейсов.
✅ Вывод: бюджет — это граница скорости.

Сравнение: Latency vs Throughput vs Concurrency

МетрикаО чёмПример
Latencyскорость ответаp95 <= 300 мс
Throughputобъём запросов200 rps
Concurrencyпараллельные пользователи1000 пользователей

Часто спрашивают на собеседованиях

  • Чем latency отличается от throughput? скорость ответа vs объём запросов.
  • Почему нужен p95, а не среднее? среднее скрывает «хвосты».
  • Что такое профиль нагрузки? описание пиков и нормальной нагрузки.
  • Что такое performance budget? предел по времени/весу.
  • Как формулировать performance-требование? метрика + условия + порог.
✅ Вывод: это базовые вопросы по performance.

Типичные ошибки

Ошибка 1: «быстро» без цифр

❌ «страница должна открываться быстро»
✅ «<=2 сек (p95) при 1000 users»

Ошибка 2: нет условий нагрузки

❌ «API отвечает за 200 мс»
✅ «200 мс при 100 rps»

Ошибка 3: только среднее

❌ «среднее 200 мс»
✅ «p95 <= 300 мс»

Ошибка 4: смешали фронт и бэк

❌ «страница быстрая» без уточнений
✅ отдельно LCP и API latency

Ошибка 5: нет error rate

❌ скорость указана, ошибки не учтены
✅ error rate <1%

Best Practices

  • Всегда указывайте метрику, условия и порог.
  • Используйте p95/p99 для критичных сценариев.
  • Описывайте профиль нагрузки.
  • Разделяйте фронтенд и бэкенд метрики.
  • Добавляйте допустимую долю ошибок.

Заключение

Ключевые мысли

🎯 Performance-требования = измеримая скорость.
🎯 Нужны метрики, условия и пороги.
🎯 Процентили и нагрузка дают реальную картину.
Теперь вы умеете превращать «быстро» в чёткие цифры.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «Требования к производительности (Performance Requirements)»

Пройти тест →