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

Обновлено: 15 мая 2026 г. в 09:00

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

средний

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

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

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

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

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

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

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

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

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

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

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

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

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

Контекст

Observability & Monitoring Design

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

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

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

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

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

Разбейте на этапы: edge, API, DB, кэш и . Для каждого сегмента задайте , чтобы оптимизация была измеримой.

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

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

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

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

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

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

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

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

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

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

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

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

Связано

Event-Driven Architecture

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

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

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

Профилирование CPU

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

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

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

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

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

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

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

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

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

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

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

SLO и бюджет производительности по слоям

Edge / API gateway

20-40 ms

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

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

Application service

60-120 ms

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

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

Data access (DB/cache/search)

40-120 ms

Стабильные p95/p99 на данных при росте объёма и конкурентности.

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

External dependencies

зависит от SLA провайдера

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

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

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

  • Определите ключевые : запросы в секунду, события в секунду, активные пользователи и рост данных за день.
  • Постройте базовый замер по p50/p95/p99 задержки, насыщению ресурсов и доле ошибок под текущей нагрузкой.
  • Считайте отдельно для среднего и пикового профиля: для критичных контуров обычно нужен минимум 20-30%.
  • Проверяйте масштабирование узких мест по одному: вычислительные ресурсы, IOPS хранилища, исходящий сетевой трафик и пропускную способность очереди.
  • Планируйте вместе с дорожной картой релизов и сезонностью, а не только по прошлым графикам.
  • Разделяйте синхронный пользовательский контур и контур пакетной или аналитической обработки, чтобы фоновая нагрузка не съедала .
  • Учитывайте стоимость: план ёмкости должен балансировать SLO, устойчивость и FinOps-ограничения.

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

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

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

Проверить стабильность p95/p99 и насыщение ресурсов на типичном профиле промышленной эксплуатации.

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

  • p95/p99 остаются в бюджете без роста доли ошибок.
  • CPU, память и ввод-вывод ниже триггеров насыщения.
  • Нет роста и ожидания потоков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Смотреть только на среднюю задержку и игнорировать p95/p99/p999.

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

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

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

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

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

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

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

Источники

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

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

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