System Design Space
Граф знанийНастройки

Обновлено: 25 июня 2026 г. в 04:10

Инженерия производительности

средний

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

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

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

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

Практическая польза главы

Практика проектирования

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

Качество решений

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

Аргументация на интервью

Структурируйте ответ вокруг жизненного цикла надёжности: сигнал деградации, реакция, локализация причины, восстановление и профилактика повторов.

Формулировка компромиссов

Явно фиксируйте компромиссы по инженерии производительности и архитектуре с учётом ёмкости: скорость релизов, уровень автоматизации, стоимость наблюдаемости и операционная сложность.

Контекст

Observability & Monitoring Design

Без метрик, логов и трассировки инженерия производительности быстро превращается в догадки.

Открыть главу

Когда систему уже разогнали постфактум, цена ошибки видна сразу: каждый процент ускорения стоит дороже, а часть узких мест уже зашита в архитектуру. Инженерия производительности переносит этот разговор в начало и проектирует , и запас ёмкости как свойства архитектуры. Дальше в главе эти свойства разложены на хвостовую задержку, бюджет задержек, профилирование, узкие места, нагрузочное тестирование, целевые уровни сервиса и стоимость самого ускорения.

Оптимизация задержки

Путь запроса и бюджет задержек

Разбейте на этапы: пограничный слой (edge), интерфейс приложения (API), базу данных, кэш и . Пока на каждый сегмент не назначен , любое ускорение остаётся спором о вкусах, а не измеримым результатом.

Снижение сетевых обменов

Уменьшайте количество : объединяйте запросы, переиспользуйте соединения, поддерживайте соединения открытыми и держите часто взаимодействующие сервисы ближе друг к другу.

Доступ к данным

Чаще всего время теряется не в коде, а в данных: проверьте индексы, , локальность данных, и защиту от проблемы N+1 запросов, когда один список тихо превращается в сотни обращений к базе.

Очереди и асинхронные границы

Выносите некритичные операции за , чтобы защищать 95-й и 99-й перцентили критического пользовательского пути от фоновой работы.

Управление хвостовой задержкой

Для важны страховочные дублирующие запросы, , адаптивные повторные попытки и защита от .

Параллелизм и обратное давление

Ограничивайте параллелизм на критичных ресурсах: базе данных, и внешних программных интерфейсах (API). помогает не довести систему до обвала при пиках, отбрасывая лишнее раньше, чем переполнятся очереди.

Деградация по приоритетам

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

Связано

Event-Driven Architecture

Асинхронные границы и очередь задач часто убирают задержку с синхронного пути.

Открыть главу

Профилирование: где именно теряется время

Профилирование процессора (CPU)

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

Профилирование памяти

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

Профилирование ввода-вывода

Разделяйте ожидание сети, диска, и задержку внешних API, иначе причина деградации быстро размазывается по слоям.

Распределённая трассировка

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

Блокировки и состояния потоков

Разбирайте очереди ожидания, и блокировки: многие всплески задержки возникают из-за конкуренции за ресурс, а не из-за загрузки процессора (CPU) — и графики утилизации тут только запутывают.

GC и паузы среды выполнения

Анализируйте , частое создание короткоживущих объектов и , особенно в сервисах с высоким числом запросов в секунду.

Целевой уровень сервиса и бюджет производительности по слоям

Edge / API gateway

20-40 ms

Маршрутизация, проверка доступа и ограничение частоты запросов без заметной задержки для клиента.

  • Кэширование политик и ключей, минимум синхронных внешних вызовов.
  • и возобновление сессий протокола защиты транспортного уровня.
  • Жёсткие тайм-ауты на нижележащие зависимости и ответа.

Application service

60-120 ms

Основная бизнес-логика и координация соседних сервисов в рамках целевого уровня сервиса.

  • Параллелизация независимых вызовов и запрет .
  • Идемпотентные повторные попытки только в пределах .
  • Ограничение и защита от проблемы N+1 запросов.

Data access (DB/cache/search)

40-120 ms

Стабильные 95-й и 99-й перцентили на данных при росте объёма и конкурентности.

  • Проверки регрессии перед релизом.
  • Разделение чтения и записи, локальный кэш и защита от .
  • Контроль , ожидания блокировок и медленных запросов.

External dependencies

зависит от соглашения об уровне сервиса провайдера

Ограничить радиус поражения внешней деградации на пользовательский путь.

  • Размыкатель цепи, резервный сценарий и изоляция по отсекам.
  • Асинхронная очередь для некритичных интеграций.
  • Отдельный целевой уровень сервиса для внешних переходов и контракт по тайм-аутам.

Планирование ёмкости

  • Определите ключевые : запросы в секунду, события в секунду, активные пользователи и рост данных за день.
  • Постройте базовый замер по 50-му, 95-му и 99-му перцентилям задержки, насыщению ресурсов и доле ошибок под текущей нагрузкой.
  • Считайте отдельно для среднего и пикового профиля: для критичных контуров обычно нужен минимум 20-30%.
  • Проверяйте масштабирование узких мест по одному: вычислительные ресурсы, число операций ввода-вывода в секунду (IOPS) для хранилища, исходящий сетевой трафик и пропускную способность очереди.
  • Планируйте вместе с дорожной картой релизов и сезонностью, а не только по прошлым графикам.
  • Разделяйте синхронный пользовательский контур и контур пакетной или аналитической обработки, чтобы фоновая нагрузка не съедала .
  • Запас ёмкости не бесплатен: план должен балансировать целевой уровень сервиса, устойчивость и бюджет, иначе практики управления облачными затратами (FinOps) урежут его за вас.

Матрица нагрузочного тестирования

Базовая устойчивая нагрузка

Ровная нагрузка 30-60 минут

Проверить стабильность 95-го и 99-го перцентилей и насыщение ресурсов на типичном профиле промышленной эксплуатации.

Критерии успеха

  • 95-й и 99-й перцентили остаются в бюджете без роста доли ошибок.
  • Процессор (CPU), память и ввод-вывод ниже триггеров насыщения.
  • Нет роста и ожидания потоков.

Ступенчатый рост нагрузки

Пошаговое увеличение нагрузки каждые 5-10 минут

Найти порог деградации и первый .

Критерии успеха

  • Известна точка, где начинает расти хвостовая задержка.
  • Понятно, какой ресурс насыщается первым: процессор (CPU), база данных (DB), сеть или блокировка.
  • Есть план, как сдвинуть ограничение в следующем релизе.

Резкий всплеск

Короткий пик в 2-5 раз выше базовой нагрузки

Проверить автомасштабирование, буферизацию очередей и под всплеском.

Критерии успеха

  • Сервис не уходит в каскадный отказ.
  • Ошибки остаются контролируемыми и восстановимыми.
  • Время возврата к норме прогнозируемо.

Длительный нагрузочный тест

Длительный тест 6-24 часа

Поймать то, что прорастает за часы, а не за минуты: утечки памяти, деградацию кэша, накопление фрагментации и медленный дрейф задержки.

Критерии успеха

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

Операционный регламент оптимизации: от гипотезы до эффекта

Операционный регламент оптимизации

6 шагов от базового замера до устойчивого эффекта
Измерение
Диагностика
Эксперимент
Проверка
Эксплуатация
Нажмите «Запуск», чтобы пройти процесс оптимизации по шагам.

Типичные антипаттерны

Оптимизировать без базовых метрик и воспроизводимого нагрузочного сценария.

Смотреть только на среднюю задержку и игнорировать 95-й, 99-й и 99.9-й перцентили.

Лечить задержку только железом, не устраняя архитектурные узкие места.

Делать бесконечные повторные попытки без бюджета и паузы с нарастающей задержкой при частичной деградации.

Планировать ёмкость без учёта и функций, которые изменят профиль нагрузки.

Смешивать оптимизации производительности и функциональные изменения в одном релизе без изоляции эффекта.

Игнорировать влияние сборщика мусора, аллокатора и блокировок, фокусируясь только на запросах SQL или кэше.

Практический чек-лист

  • Для критичных пользовательских путей определены 95-й и 99-й перцентили целевого уровня сервиса и бюджет задержек по слоям.
  • Есть регулярный для устойчивой нагрузки и стресс-сценарии для всплесков и ступенчатого роста.
  • Профилирование процессора (CPU), памяти, ввода-вывода и блокировок выполняется до и после оптимизаций — иначе непонятно, что именно дал релиз.
  • Контролируются метрики насыщения: утилизация пулов, глубина очередей, ожидание потоков, паузы сборщика мусора.
  • Повторные попытки, тайм-ауты и размыкатели цепи согласованы между сервисами и не создают шторм повторных попыток.
  • включены в процесс выпуска изменений для ключевых API и запросов.
  • План ёмкости пересматривается вместе с дорожной картой (roadmap) и сезонными пиками нагрузки.
  • Команда фиксирует итоги оптимизаций в операционной инструкции (runbook) или записи архитектурного решения (ADR): что помогло, где риски и как это мониторить.

Источники

Производительность — это не разовый замер для сравнения, а постоянный инженерный цикл обратной связи: измерили, нашли узкое место, исправили, проверили снова.

Связанные главы

Чтобы отмечать прохождение, включи трекинг в Настройки